Intelligent Appointment Suggestions

ABSTRACT

Some embodiments provide a method for automatically generating an appointment for an electronic calendar. The method receives input to create a new appointment for the calendar. The method analyzes several previous appointments stored for the first calendar. Based on the analysis, the method automatically proposes a new appointment that has at least one appointment characteristic shared with at least one past appointment stored for the calendar. In some embodiments, the method receives text input describing a characteristic of the new appointment, and searches through the previous appointments using the text input.

BACKGROUND

In the modern world, people regularly use electronic scheduling orcalendar applications to keep track of their appointments. Thesecalendar applications operate on both mobile devices (e.g., tablets,smart phones) as well as personal computers (e.g., laptops, desktops).In some cases, the user may synchronize their calendars across platforms(e.g., through a centralized server or a cloud storage account). Asthese calendar applications become more ubiquitous, further improvementsto make the applications easier to use are desired.

BRIEF SUMMARY

Some embodiments provide a calendar application with one or more ofseveral novel features. In some embodiments, the calendar applicationoperates on a mobile device (e.g., a smart phone, tablet, etc.) with atouchscreen display. The calendar application of some embodimentsenables a user to modify the time scale of calendar layouts throughgestural touch input. In addition, some embodiments allow users tospecify a particular time zone for an appointment. When the applicationdisplays a calendar layout for a different time zone, the applicationprovides information regarding the specified time zone as part of arepresentation of the appointment in the calendar layout. In addition,the calendar application of some embodiments provides support forcommenting within a new messages inbox, both in the presentation ofcomments sent to a user of the calendar application by invitees forappointments organized by the user, as well as providing the user withthe ability to more easily comment on appointments to which the user hasbeen invited. The calendar application of some embodiments additionallyprovides support for identifying an optimal time to set up anappointment, by accessing the calendars of invitees and identifyingwhich invitees are not available at proposed appointment times, as wellas proposing times at which the invitees are available. Lastly, thecalendar application of some embodiments automatically analyzes the pasthistory of a user's calendar in order to propose new appointments forthe user.

As mentioned, some embodiments provide the ability for a user of thecalendar application to modify the time scale of calendar layoutsthrough gestural touch input. Specifically, the user either increases ordecreases the time scale (i.e., the amount of the display screenoccupied by one hour of the calendar), thereby correspondinglyincreasing or decreasing the size of representations of appointments inthe calendar. In some embodiments, the user provides multi-touchgestural input in order to perform the resizing of the time scale in thecalendar layout. As the user increases the size of the representations,some embodiments display additional information about the appointment inthe representation (e.g., a location of the appointment, attendees ofthe appointment, etc.). In some embodiments, as the user decreases thesize of the representations, the application modifies the size of thetext in the representation of the appointment. At a certain point, forshort (e.g., 15 minute or 30 minute) appointments, rather than displayunreadable text, the application removes the text from the calendarlayout altogether.

When users specify time zone information for an appointment, thecalendar application of some embodiments incorporates this informationinto the representation of the appointment in the calendar layout. Whencreating an event, a user may specify a time zone for the event (e.g.,the time zone in which the event will take place). The calendarapplication, in some embodiments, displays representations of the user'sappointments according to the time zone in which the mobile devicerunning the application is located. As a result, in some cases thecalendar application displays the calendar in a first time zone, whiledisplaying a representation for an appointment for which a second timezone is specified. In such cases, some embodiments display therepresentation at its corresponding time in the first time zone, butindicate within the representation the second time zone and thespecified time in that second time zone for the appointment.

As indicated, the calendar application of some embodiments providessupport for commenting within a new messages inbox. Specifically, theapplication of some embodiments aggregates both new messages invitingthe user of the application to appointments as well as messagesregarding appointments organized by the user of the application (e.g.,invitees commenting on and/or declining the appointment). When multipleinvitees have commented on and/or declined the appointment, someembodiments aggregate these communications into a single entry in theuser interface. In some embodiments, the user can select one of thesemessages (or aggregated sets of messages) to view further detailedinformation about the appointment, including information indicating (i)whether invitees have responded, (ii) what the invitees' responsesindicated, and (iii) whether the invitees had comments about theappointment. In addition, some embodiments provide a separate selectableitem for each of the messages (or aggregated sets of messages) to accessa page with more detailed information about the invitees of theappointment. This page, in some embodiments, also provides indication asto which invitees have responded, as well as indicators (e.g., graphicalindicators) about whether responding invitees indicated they willattend. In addition, the page provides the full text of any comments theinvitees may have had regarding the appointment.

When a user of the calendar application declines an appointment (throughan invitation message in the same inbox in some embodiments), theapplication automatically provides the user with the ability to add acomment to a communication that will be sent to the organizer of theappointment, rather than sending the communication right away. The usercan then type in a comment (e.g., through a touchscreen keyboard), andaccept or decline other invitations present in the inbox. The calendarapplication holds off on sending the communications indicatingacceptance/declining of an invitation until the user provides inputindicating that she has completed actions in the inbox (e.g., byreturning to the calendar layout).

The application of some embodiments further provides informationregarding the availability of proposed participants for a newappointment, to aid in scheduling the appointment. In some embodiments,when a user enters a new invitee for an appointment (for which the useris the organizer), the application automatically accesses the invitee'scalendar (e.g., by accessing a server) and displays an indicator (e.g.,a graphical indicator) that indicates whether or not the invitee isavailable at an initially scheduled time for the appointment. When theapplication cannot access a particular invitee's calendar (e.g., becausethe server is inaccessible or the application does not have the requiredpermissions), then the application displays an indicator that theinvitee's availability is unknown. Once the user has finished addinginvitees for the appointment, the application identifies any schedulingconflicts and proposes additional new times at which the invitees areavailable. Some embodiments display (i) the invitees that are notavailable at the currently scheduled time for the appointment, (ii) atleast one upcoming time at which all invitees (and the organizer of themeeting), and (iii) upcoming times at which various subsets of theinvitees are available. The application presents selectable items foreach of these upcoming times, enabling the organizer to select the timeas a new time for the appointment, or to view the appointment in hercalendar at the upcoming time.

In addition to analyzing the calendars of invitees to determine upcomingtimes for an appointment, some embodiments provide a new appointmentfeature that analyzes the past calendar history of a user in order topropose likely appointments for the user, with appointment details. Whenthe user selects a quick appointment feature in the calendarapplication, the application generates the set of likely appointments.In some embodiments, the application provides a first option for theuser to name an appointment which will be created at the first open timeslot in the user's calendar, without any additional details (i.e., forthe user to fill in the details). In addition, the application providesone or more selectable items for proposed appointments at variousupcoming times, with additional appointment details already specified.

The calendar application of some embodiments identifies patterns (e.g.,recurring meetings) in the user's past calendar history, then proposesappointments that continue such patterns. For example, if the user hashad an appointment with the same name at the same time on the same dayof the week for the past several weeks, then the application proposes anappointment with that name at the same time on the next occurrence ofthe particular day of the week. If the recurring time is occupied by adifferent appointment, then the application of some embodimentsidentifies a nearby time (e.g., just before or just after) and proposesthe new appointment at the nearby time. If additional details (e.g., thelocation, invitee list, etc.) are the same or similar throughout therecurrences, the application uses these additional details for theproposed appointment. Similarly, the application might identifyappointments held every other week, every day, on the same day of themonth for several months, etc. The application might identify otherpatterns, such as the same set of invitees at numerous appointments(with numerous different times and appointment names), and propose a newappointment for the set of invitees at the next available time. Once theuser selects a proposed appointment, the application adds thisappointment to the calendar of the user, and the user can edit thedetails (e.g., change the time, invitees, location, etc.) before sendinginvitations to the appointment to the finalized list of invitees.

The preceding Summary is intended to serve as a brief introduction tosome embodiments of the invention. It is not meant to be an introductionor overview of all inventive subject matter disclosed in this document.The Detailed Description that follows and the Drawings that are referredto in the Detailed Description further describe the embodimentsdescribed in the Summary as well as other embodiments. Accordingly, tounderstand all the embodiments described by this document, a full reviewof the Summary, the Detailed Description, and the Drawings is needed.Moreover, the claimed subject matters are not to be limited by theillustrative details in the Summary, the Detailed Description, and theDrawings, but rather are to be defined by the appended claims, becausethe claimed subject matters can be embodied in other specific formswithout departing from the spirit of the subject matters.

BRIEF DESCRIPTION OF THE DRAWINGS

The novel features of the invention are set forth in the appendedclaims. However, for purposes of explanation, several embodiments of theinvention are set forth in the following figures.

FIG. 1 illustrates a graphical user interface (GUI) of a calendarapplication of some embodiments as a user increases the time scale(i.e., increases the portion of the layout occupied by a unit of time),then returns the GUI to a default time scale.

FIG. 2 illustrates the maintaining of a modified time scale fordifferent days of a calendar layout.

FIG. 3 illustrates the GUI as the user decreases the time scale (i.e.,decreases the portion of the layout occupied by a unit of time).

FIG. 4 illustrates a landscape orientation GUI of a calendar applicationof some embodiments as a user increases the time scale, then decreasesthe time scale, then returns to the default time scale by providingvarious touch inputs.

FIG. 5 conceptually illustrates a state diagram that shows states andchanges between states for the calendar layout GUI of some embodiments.

FIG. 6 illustrates a user modifying the time zone for a new event.

FIGS. 7 and 8 illustrate the calendar layout GUI of some embodiments intwo different circumstances for the same calendar.

FIG. 9 conceptually illustrates a process of some embodiments fordisplaying appointment representations in a calendar layout.

FIG. 10 illustrates a user accessing the calendar message user interfaceof some embodiments.

FIG. 11 illustrates an example of a user declining an appointment andcommenting on the appointment in the calendar message user interface ofsome embodiments.

FIG. 12 illustrates a user declining multiple appointments in thecalendar messages GUI.

FIG. 13 illustrates the same flow as FIG. 12, except that the useraccepts one of the invitations rather than declining it.

FIG. 14 conceptually illustrates a state diagram that shows states andchanges between states for the calendar message GUI of some embodiments.

FIGS. 15 and 16 illustrate the creation of an appointment, andspecifically the addition of invitees to an appointment while creatingthe appointment.

FIG. 17 conceptually illustrates a process for displaying a graphicalindicator when an invitee is added to an appointment.

FIGS. 18 and 19 illustrate an invitee scheduling GUI of some embodimentsfor displaying scheduling conflicts and alternate times for a newappointment.

FIG. 20 illustrates the use of a selectable item for viewing a proposedalternate time in the user's calendar.

FIG. 21 illustrates the selection of an alternate proposed time, and theeffect thereof on the invitee scheduling GUI.

FIG. 22 conceptually illustrates a process of some embodiments forgenerating and preparing proposed times for display in the schedulingGUI.

FIG. 23 illustrates an appointment organizer e-mailing all of theinvitees of an appointment.

FIG. 24 illustrates a monthly view GUI of a user's schedule.

FIGS. 25 and 26 illustrate the generation of new appointment options ina daily view GUI of some embodiments.

FIGS. 27A-B illustrate the selection of one of the proposed appointmentoptions and the subsequent creation of a new appointment in the user'scalendar.

FIG. 28 conceptually illustrates a process of some embodiments forautomatically generating proposed appointments upon receipt of an inputto create a new appointment.

FIG. 29, like FIG. 24, illustrates a monthly view GUI of a user'sschedule.

FIGS. 30 and 31 illustrate the generation of proposed new appointmentoptions in a daily view GUI of some embodiments based on user textinput.

FIG. 32 illustrates the selection of one of the proposed appointmentitems and the resulting creation of a new appointment in the user'scalendar.

FIG. 33 conceptually illustrates a process of some embodiments forautomatically generating proposed appointments based on matching textinput to a user's past calendar appointment history.

FIG. 34 is an example of an architecture of a mobile computing device ofsome embodiments.

FIG. 35 conceptually illustrates an example of an electronic system withwhich some embodiments of the invention are implemented.

DETAILED DESCRIPTION

In the following detailed description of the invention, numerousdetails, examples, and embodiments of the invention are set forth anddescribed. However, it will be clear and apparent to one skilled in theart that the invention is not limited to the embodiments set forth andthat the invention may be practiced without some of the specific detailsand examples discussed.

Some embodiments provide a calendar application with one or more ofseveral novel features. In some embodiments, the calendar applicationoperates on a mobile device (e.g., a smart phone, tablet, etc.) with atouchscreen display. The calendar application of some embodimentsenables a user to modify the time scale of calendar layouts throughgestural touch input. In addition, some embodiments allow users tospecify a particular time zone for an appointment. When the applicationdisplays a calendar layout for a different time zone, the applicationprovides information regarding the specified time zone as part of arepresentation of the appointment in the calendar layout. In addition,the calendar application of some embodiments provides support forcommenting within a new messages inbox, both in the presentation ofcomments sent to a user of the calendar application by invitees forappointments organized by the user, as well as providing the user withthe ability to more easily comment on appointments to which the user hasbeen invited. The calendar application of some embodiments additionallyprovides support for identifying an optimal time to set up anappointment, by accessing the calendars of invitees and identifyingwhich invitees are not available at proposed appointment times, as wellas proposing times at which the invitees are available. Lastly, thecalendar application of some embodiments automatically analyzes the pasthistory of a user's calendar in order to propose new appointments forthe user.

The calendar application of some embodiments allows a user to manageappointments (also referred to as events) in one or more calendars(e.g., a work calendar, a personal calendar, etc.). In some embodiments,each calendar is associated with a different e-mail address of the user.Appointments are scheduled for a particular date and time in aparticular calendar.

The calendar application allows a user to organize appointments and toreceive invitations to appointments organized by others. When organizingan appointment, the user specifies various details (the name, location,date and time, etc.) as well as the list of proposed attendees(invitees). Upon finalizing the appointment, the application sends acommunication (e.g., an e-mail) to the invitees. When the calendarapplication receives such a communication for an appointment organizedby another user of a calendar application (either the same applicationon a different device, or a different application), the applicationpresents the user with the ability to accept or decline the invitation(or respond that she is unsure of availability). When the user acceptsthe appointment, the application adds the appointment to the user'scalendar.

A user can view her calendar in a calendar layout user interface of thecalendar application. Such a user interface, in some embodiments,provides the user with a daily, weekly, monthly, or yearly view. In someor all of these views, the application displays representations of theuser's appointments in the calendar layout, along with information aboutthe appointment (e.g., the name of the appointment). The application ofsome embodiments also provides user interfaces for the user to viewdetails of an appointment, modify the details, create new appointments,view received calendar messages, etc.

As mentioned, some embodiments provide the ability for a user of thecalendar application to modify the time scale of calendar layoutsthrough gestural touch input. Specifically, the user either increases ordecreases the time scale (i.e., the amount of the display screenoccupied by one hour of the calendar), thereby correspondinglyincreasing or decreasing the size of representations of appointments inthe calendar. In some embodiments, the user provides multi-touchgestural input in order to perform the resizing of the time scale in thecalendar layout. As the user increases the size of the representations,some embodiments display additional information about the appointment inthe representation (e.g., a location of the appointment, attendees ofthe appointment, etc.). In some embodiments, as the user decreases thesize of the representations, the application modifies the size of thetext in the representation of the appointment. At a certain point, forshort (e.g., 15 minute or 30 minute) appointments, rather than displayunreadable text, the application removes the text from the calendarlayout altogether.

When users specify time zone information for an appointment, thecalendar application of some embodiments incorporates this informationinto the representation of the appointment in the calendar layout. Whencreating an event, a user may specify a time zone for the event (e.g.,the time zone in which the event will take place). The calendarapplication, in some embodiments, displays representations of the user'sappointments according to the time zone in which the mobile devicerunning the application is located. As a result, in some cases thecalendar application displays the calendar in a first time zone, whiledisplaying a representation for an appointment for which a second timezone is specified. In such cases, some embodiments display therepresentation at its corresponding time in the first time zone, butindicate within the representation the second time zone and thespecified time in that second time zone for the appointment.

As indicated, the calendar application of some embodiments providessupport for commenting within a new messages inbox. Specifically, theapplication of some embodiments aggregates both new messages invitingthe user of the application to appointments as well as messagesregarding appointments organized by the user of the application (e.g.,invitees commenting on and/or declining the appointment). When multipleinvitees have commented on and/or declined the appointment, someembodiments aggregate these communications into a single entry in theuser interface. In some embodiments, the user can select one of thesemessages (or aggregated sets of messages) to view further detailedinformation about the appointment, including information indicating (i)whether invitees have responded, (ii) what the invitees' responsesindicated, and (iii) whether the invitees had comments about theappointment. In addition, some embodiments provide a separate selectableitem for each of the messages (or aggregated sets of messages) to accessa page with more detailed information about the invitees of theappointment. This page, in some embodiments, also provides indication asto which invitees have responded, as well as indicators (e.g., graphicalindicators) about whether responding invitees indicated they willattend. In addition, the page provides the full text of any comments theinvitees may have had regarding the appointment.

When a user of the calendar application declines an appointment (throughan invitation message in the same inbox in some embodiments), theapplication automatically provides the user with the ability to add acomment to a communication that will be sent to the organizer of theappointment, rather than sending the communication right away. The usercan then type in a comment (e.g., through a touchscreen keyboard), andaccept or decline other invitations present in the inbox. The calendarapplication holds off on sending the communications indicatingacceptance/declining of an invitation until the user provides inputindicating that she has completed actions in the inbox (e.g., byreturning to the calendar layout).

The application of some embodiments further provides informationregarding the availability of proposed participants for a newappointment, to aid in scheduling the appointment. In some embodiments,when a user enters a new invitee for an appointment (for which the useris the organizer), the application automatically accesses the invitee'scalendar (e.g., by accessing a server) and displays an indicator (e.g.,a graphical indicator) that indicates whether or not the invitee isavailable at an initially scheduled time for the appointment. When theapplication cannot access a particular invitee's calendar (e.g., becausethe server is inaccessible or the application does not have the requiredpermissions), then the application displays an indicator that theinvitee's availability is unknown. Once the user has finished addinginvitees for the appointment, the application identifies any schedulingconflicts and proposes additional new times at which the invitees areavailable. Some embodiments display (i) the invitees that are notavailable at the currently scheduled time for the appointment, (ii) atleast one upcoming time at which all invitees (and the organizer of themeeting), and (iii) upcoming times at which various subsets of theinvitees are available. The application presents selectable items foreach of these upcoming times, enabling the organizer to select the timeas a new time for the appointment, or to view the appointment in hercalendar at the upcoming time.

In addition to analyzing the calendars of invitees to determine upcomingtimes for an appointment, some embodiments provide a new appointmentfeature that analyzes the past calendar history of a user in order topropose likely appointments for the user, with appointment details. Whenthe user selects a quick appointment feature in the calendarapplication, the application generates the set of likely appointments.In some embodiments, the application provides a first option for theuser to name an appointment which will be created at the first open timeslot in the user's calendar, without any additional details (i.e., forthe user to fill in the details). In addition, the application providesone or more selectable items for proposed appointments at variousupcoming times, with additional appointment details already specified.

The calendar application of some embodiments identifies patterns (e.g.,recurring meetings) in the user's past calendar history, then proposesappointments that continue such patterns. For example, if the user hashad an appointment with the same name at the same time on the same dayof the week for the past several weeks, then the application proposes anappointment with that name at the same time on the next occurrence ofthe particular day of the week. If the recurring time is occupied by adifferent appointment, then the application of some embodimentsidentifies a nearby time (e.g., just before or just after) and proposesthe new appointment at the nearby time. If additional details (e.g., thelocation, invitee list, etc.) are the same or similar throughout therecurrences, the application uses these additional details for theproposed appointment. Similarly, the application might identifyappointments held every other week, every day, on the same day of themonth for several months, etc. The application might identify otherpatterns, such as the same set of invitees at numerous appointments(with numerous different times and appointment names), and propose a newappointment for the set of invitees at the next available time. Once theuser selects a proposed appointment, the application adds thisappointment to the calendar of the user, and the user can edit thedetails (e.g., change the time, invitees, location, etc.) before sendinginvitations to the appointment to the finalized list of invitees.

The above paragraphs describe examples of the novel calendar applicationfeatures of some embodiments. Several more detailed examples aredescribed below. Section I describes the modifying the time scale of acalendar layout of some embodiments. Section II then describes the useof time zone information for appointments and the display of thatinformation in the calendar layout of some embodiments. Next, SectionIII describes features that enable the user to easily comment onappointment invitations in some embodiments, while Section IV describesfeatures of the calendar application of some embodiments for schedulingappointments based on participant availability. Section V describes afeature of the calendar application of some embodiments forautomatically suggesting new appointments based on a user's calendarhistory. Finally, Section VI describes electronic systems with whichsome embodiments of the invention are implemented.

I. Resizing a Calendar Layout

As mentioned, the calendar application of some embodiments provides theability for a user to modify the time scale of calendar layoutsdisplayed in the user interface of the application through gesturaltouch input. Specifically, the user either increases or decreases thetime scale (i.e., the amount of the display screen occupied by one houror other unit of time of the calendar), thereby correspondinglyincreasing or decreasing the size of representations of appointments inthe calendar. In some embodiments, the user provides multi-touchgestural input in order to perform the resizing of the time scale in thecalendar layout. As the user increases the size of the representations,some embodiments display additional information about the appointment inthe representation (e.g., a location of the appointment, attendees ofthe appointment, etc.). In some embodiments, as the user decreases thesize of the representations, the application modifies the size of thetext in the representation of the appointment. At a certain point, forshort (e.g., 15 minute or 30 minute) appointments, rather than displayunreadable text, the application removes the text from the calendarlayout altogether.

FIG. 1 illustrates a graphical user interface (GUI) 100 of a calendarapplication of some embodiments as user input increases the time scale(i.e., increases the portion of the layout occupied by a unit of time),then returns the GUI to a default time scale over six stages 105-130.Specifically, in the second and third stages 110 and 115, the userprovides multi-touch gestural input to increase the time scale, while inthe fifth stage 125 the user provides a different touch input to returnto the default time scale.

The first stage 105 illustrates the calendar layout GUI 100 of someembodiments. In some embodiments, the application operates on atouchscreen mobile device (e.g., a smart phone, tablet, etc.), and theGUI 100 is displayed on (and receives input through) the touchscreendisplay of the mobile device. As shown, the GUI 100 includes a set ofselectable items 135, a set of calendar navigation items 140, a calendarlayout 145, and a set of application navigation items 149.

The set of selectable items 135, in some embodiments, includes acalendar layout format change item 136, a search item 137, and a newevent creation item 138. In some embodiments, selecting the calendarlayout format change item 136 (e.g., via tapping the item on thetouchscreen display) causes the application to display a calendar listview rather than the hourly calendar layout 145. The calendar list view,in some embodiments, displays a list of upcoming appointments sorted bydate and time. Selection of the search item 137 causes the applicationto present a search bar for searching the calendar. Selection of the newevent creation item 138 causes the application to open a new eventcreation GUI through which the user can enter details for a new event.

The set of calendar navigation items 140, in some embodiments, includesselectable items for each day of the current week, as well as aselectable item 141 for navigating upwards in the time hierarchy (i.e.,to a different layout for the entire month rather than a particular weekand day). Each of the selectable items for the different days of theweek can be selected in order to cause the application to display theuser's schedule for the selected day in the calendar layout 145. Thecurrently selected day (May 6^(th), in this example), is indicated by agraphical indicator around the date (i.e., the circle shown around the“6”).

The calendar layout 145 of some embodiments displays representations ofthe appointments scheduled in the user's calendar for the currentlyselected day. The calendar layout 145 displays time markers (e.g., everyhour, every half hour, every two hours, etc.), in this case starting at1 PM (the next hour after the current time of 12:30 PM) and ending at 9PM. The time markers (and, correspondingly, the calendar) are spacedaccording to a time scale for the layout, which determines the length oftime for which the schedule is shown in the layout. Within the calendarlayout 145, the application displays representations 150-170 of fiveappointments scheduled in the user's calendar. These representationshorizontally span the width of the calendar layout 145, and verticallyeach span their respective time slots. Thus, the representation 150 for“Meeting 1”, an appointment scheduled from 1 PM to 2 PM, spans theportion of the calendar layout 145 representing this time. Similarly,the representation 155 spans the portion of the calendar layout 145 from3 PM to 4 PM, etc. Each of these representations displays theappointment name (“Meeting 1”, “Soccer Practice”, etc.). In someembodiments, the representations also display the location of theappointment if this information is available and fits within therepresentation.

The set of application navigation items 149 includes a today item 151, acalendars selection item 152, and an inbox access item 153. Selection ofthe today item 151 navigates the calendar layout 145 to the current day.Selection of the calendars item 152 causes the application to open adialog window in which the user can choose what will be displayed in thecalendar layout 145. For instance, the user can select from differentcalendars (e.g., associated with different e-mail addresses or otheraccounts), whether to display holidays, saved birthdays of contacts,etc. The inbox access item 153 enables the user to access a calendarmessage user interface, which is described in greater detail below inSection III.

The second stage 110 illustrates that the user is providing multi-touchgestural input through the display screen over the calendar layout 145.Specifically, the user inputs a pull-apart two-finger gesture centerednear 7 PM in the calendar layout. This multi-touch gestural input causesthe calendar application to modify the time scale of the calendarlayout.

Specifically, as shown in the third stage 115, the application increasesthe portion of the calendar layout 145 represented by each hour, suchthat a smaller portion of the schedule is shown within the layout. Thatis, the application zooms in on a portion of the calendar layoutcentered near 7 PM. However, this zoom is only in the verticaldirection; the horizontal aspect of the calendar layout 145 isunchanged. Some embodiments zoom in about the center of the layout 145(which would be near 5 PM in the current example), while otherembodiments (as shown in this example) zoom in about the center of thegestural input. As a result of the modification to the time scale, onlythe appointment representations 160 and 165 (and a small portion of therepresentation 170) remain displayed in the calendar layout 145 in thethird stage 115. These appointment representations 160 and 165 haveincreased in size in correspondence with the time scale of the calendarlayout, and additionally now each display the location of theappointment (“Office” and “City Park”) as well as the appointment name.In this third stage 115, the user also continues the multi-touchgestural pull-apart input.

The fourth stage 120 illustrates the GUI 100 after the user hascompleted the multi-touch gestural input begun in the second stage 110.The time scale has been further modified compared to the third stage 115such that the calendar layout 145 only displays less than an hour and ahalf of the user's schedule, with only the representation 165 displayedin the layout. The appointment representation 165 displays, in additionto the appointment name, a list of the attendees of the meeting (otherthan the user of the calendar application). Some embodiments do notdisplay additional information beyond the title and location of theappointment. On the other hand, some embodiments display moreinformation as the appointment representation is enlarged, including theattendees or invitees, any notes about the meeting, the number ofinvitees who have accepted or declined the meeting, etc.

In the fifth stage 125, the user provides a different touch input (adouble tap, specifically) over the calendar layout 145. This causes theapplication, as shown in stage 130, to return the calendar layout 145display to its default time scale, similar to that shown in the firststage 105. As a result, all of the appointment representations 150-170are now displayed within the GUI 100, at the same size as in the firststage 140.

In this figure, as well as throughout this document, various specifictouch inputs are illustrated and described. However, one of ordinaryskill in the art will recognize that different embodiments may usedifferent types of input (either multi-touch inputs, single-touchinputs, near-touch inputs, or non-touch inputs such as inputs fromcursor controllers, physical buttons, etc.) to perform the operationsshown in the figures. Thus, inputs other than the pull-apart multi-touchgesture and the double-tap touch input might be used to modify the timescale and return to a default time scale, just as inputs other thanthose shown in the subsequent figures could be performed rather than thegestures shown in the subsequent figures.

In some embodiments, the user may change the time scale of the calendarlayout, then change the day for which the calendar is displayed in thelayout. In some such embodiments, the calendar application keeps thetime scale for the newly selected day. That is, the application makesthe new time scale for the calendar layout “sticky” across the schedulesfor different time periods.

FIG. 2 illustrates the maintaining of a modified time scale fordifferent days of a calendar layout over four stages 205-220 of the GUI100. The first stage 205 illustrates the GUI 100 in the same state as inthe first and second stages 105 and 110 of the previous figure.Additionally, at this stage, the user performs the same gestural inputas in the stages 110 and 115 of FIG. 1, with the resultant second stage210 being the same as stage 120 of that figure. At this point, the timescale has been modified such that the calendar layout displays slightlyless than an hour and a half of the schedule for May 6, from a bitbefore 6 PM up to nearly 7:30 PM.

In the third stage 215, the user selects a selectable item 225representing Wednesday, May 7. In this case, the user makes thisselection via a tap gesture over the selectable item. As this is thenext day after the currently displayed day, some embodiments allow thesame calendar navigation via a leftward swipe gesture over the calendarlayout 145.

The resultant stage 220 displays the user's schedule for Wednesday, May7. Because the user had modified the time scale before changing thedisplayed day, the application maintains the modified time scale (aswell as the portion of the day's schedule shown in the calendar layout).Thus, the calendar layout 145 now displays the portion of the user'sschedule from shortly before 6 PM to almost 7:30 PM, which includes anappointment representation 230 for an appointment “Dinner With Client”.Because the representation 230 occupies a large portion of the calendarlayout 145, the application displays the location and attendees for theappointment (or other information in other embodiments).

In addition to modifying the time scale to enlarge the portion of thecalendar layout represented by one hour, the application of someembodiments also allows users to modify the time scale of the calendarlayout in the opposite direction. That is, through gestural input theuser can modify the time scale of the calendar layout such that eachhour occupies a smaller portion of the calendar layout and more time ofthe day is displayed within the layout.

FIG. 3 illustrates the GUI 100 as the user decreases the time scale(i.e., decreases the portion of the layout occupied by a unit of time)over four stages 305-320. The first stage 305 illustrates the calendarlayout 145 in a default time scale. The schedule illustrates fiveappointment representations 325-345, which are similar to theappointment representations 150-170 in the example above. However, inthis case, the appointments “Meeting 1” and “Meeting 2” are each only ahalf hour long, and thus their corresponding representations in thecalendar layout 145 are smaller.

In the second stage 310, the user begins providing multi-touch gesturalinput through the touchscreen display over the calendar layout 145.Whereas the previous figures illustrate the user inputting a pull-apartgesture with two fingers, in this case the user provides a pinchinggesture to cause the calendar application to modify the time scale ofthe calendar layout.

Specifically, as shown in the third stage 315, the application decreasesthe portion of the calendar layout 145 represented by each hour, suchthat a larger portion of the schedule is shown within the layout. Thatis, the application zooms out from a portion of the calendar layoutcentered near 7 PM. As in the previous figures, this zoom operation isonly in the vertical direction; the horizontal aspect of the calendarlayout 145 is unchanged. Some embodiments zoom out about the center ofthe layout 145 (which would be near 5 PM in the present example), whileother embodiments zoom out about the center of the gestural input (asshown in this case). Furthermore, some embodiments also may modify thecenter of the zoom due to the time boundaries of the selected day. Thatis, the application of some embodiments does not continue into theschedule of the previous or subsequent day, and thus may increase thetime shown in the calendar layout at either only the top or only thebottom of the layout once 12 AM is reached on either side. As a resultof the modification to the time scale, the appointment representations325-345 have decreased in size in correspondence with the time scale ofthe calendar layout. Furthermore, the size of the text for each of theappointment representations has decreased so as to fit within theappointment representations. In this third stage 315, the user continuesthe multi-touch gestural pinch input.

The fourth stage 320 illustrates the GUI 100 after the user hascompleted the multi-touch gestural input begun in the second stage 310.The time scale has been further modified compared to the third stage 315such that the the calendar layout 145 now displays the user's schedulefrom approximately 9:30 AM to midnight on the selected day, May 6. Oncemidnight is reached at the end of the selected day, further decreasingof the time scale causes only earlier times to appear at the top of theUI. In addition, the text for appointment representations 330, 340, and345 has continued to decrease in size.

The application has also removed the text for appointmentrepresentations 325 and 335, which are shorter meetings of only half anhour. Some embodiments, once the appointment representation becomessmaller than a threshold size, remove the text altogether rather thandisplaying difficult or impossible to read information text. Thisthreshold may be based on a size of the representation, a length in timeof the appointment for certain time scales, etc. In some embodiments,the text is replaced with a graphical indicator that informs the userthat text is replaced. In order to view the text, the user can selectthe event (to cause the application to display an event details GUI) orprovide gestural input to modify the time scale. For instance, just asshown in FIG. 1 for increased time scales, the user may provide input toreturn to the default time scale after decreasing the time scale (e.g.,double tap input). Furthermore, after decreasing the time scale, theuser could provide input to cause the calendar application to switch theday for which it displays the schedule, and the decreased time scalewould be used for the newly displayed schedule as well.

The calendar layout GUI 100 shown in the previous three figures is theGUI shown when the mobile device on which the application operates isoriented in the portrait orientation. Some embodiments display adifferent calendar layout GUI for landscape orientation, with similarresizing properties to the portrait orientation GUI.

FIG. 4 illustrates such a landscape orientation GUI 400 of a calendarapplication of some embodiments as a user increases the time scale, thendecreases the time scale, then returns to the default time scale byproviding various touch input over five stages 405-425. Specifically, inthe second stage 410 the user provides multi-touch gestural input toincrease the time scale, in the third stage 415 the user providesmulti-touch gestural input to decrease the time scale, and in the fourthstage 420 the user provides a different touch input to return to thedefault time scale.

The first stage 405 illustrates the landscape orientation calendarlayout GUI 400 of some embodiments. The GUI 400 includes a header row430, an all-day event row 435, and a calendar layout 440. The header row430 displays several days of the week, as well as the month to which thedays of the week belong. While this figure illustrates the GUI 400 asdisplaying slightly more than three days of the week, some embodimentsformat the width such that five days (i.e., one work week) aredisplayed. In some embodiments, the number of days displayed within thelandscape orientation layout is a variable that the user may modify. Inaddition, some embodiments highlight the current day of the week (e.g.,with a circle around its number) when that day is displayed within theGUI 400.

The all-day event row 435, in some embodiments, is displayed in someembodiments only when one of the days in the currently displayed weekhas an all-day event (even if that day is not currently displayed withinthe calendar layout. Such events might be pre-programmed events such asholidays, as well as scheduled appointments (e.g., conferences).

The calendar layout 440 is similar to the layout 145, except that thelayout 440 spans multiple days. The calendar layout 440 also has timemarkers on the left side running vertically, and includes appointmentrepresentations within the displayed schedule that represent the user'sappointments during the displayed days.

In the second stage 410, the user provides a multi-touch gestural inputthrough the display screen over the calendar layout 440. Specifically,the user inputs a pull-apart two-finger gesture, which causes theapplication to increase the time scale of the calendar layout 440. As aresult, the third stage 415 illustrates that the calendar layout 440displays only two hours of the user's schedule for these three daysrather than the four and a half hours of the previous stage. Inaddition, the appointment representation 445 for a doctor appointmentnow shows the location of that appointment, and the appointmentrepresentation 450 shows the full title of the appointment (“LunchMeeting”).

The third stage 415 also illustrates that the user is now providing amulti-touch pinch gestural input over the calendar layout, in order todecrease the time scale of the calendar layout 440. The fourth stage 420illustrates the resultant calendar layout 440, with approximately eighthours of the user's schedule illustrated in the layout. The text size ofsome of the appointment representations has decreased, and for theappointment representation 455 (for “Meeting 2”), the application hasremoved the text completely. In both of the third and fourth stages415-420, the all-day event row 435 does not change in height. However,in other embodiments, the application correspondingly increases ordecreases the height of this all-day event row (if present). The useralso provides a double tap input in the fourth stage 420, and in thefifth stage 425, the application has returned the calendar layout 440 tothe default time scale from the first stage 405.

FIG. 5 conceptually illustrates a state diagram 500 that shows statesand changes between states for the calendar layout GUI of someembodiments. One of ordinary skill in the art will recognize that thisstate diagram does not cover every possible interaction with thecalendar layout. For instance, the state diagram does not describechanging the day (or days, in the landscape orientation) for which theapplication displays a user's schedule, or scrolling up and down withina day's schedule. Instead, the state diagram 500 is restricted tomodifications to the time scale of the calendar layout. In each of thestates shown in the state diagram 500, the operations of the calendarapplication are controlled by one or more application processes that areresponsible for handling the user interaction with the calendarapplication GUI.

When the user is not interacting with the calendar layout 500, the GUIis in state 505, at which the calendar application displays the calendarlayout statically. That is, when no input is received (and theapplication is displaying the calendar layout GUI), the applicationdisplays this GUI statically.

When a first type of gestural input is received (e.g., the pull-apartmulti-touch gesture shown in FIG. 1), the application transitions tostate 510 to increase the size of the time units of the calendar layout.That is, the application increases the portion of the calendar layoutthat each hour (or half hour, or other time unit) occupies as thegestural input is received, as shown in FIG. 1. As this input continues,the application remains in the state 510 until either a threshold ispassed (causing a transition to state 515 or 520) or the gestural inputceases (causing a transition back to state 505).

As shown, when the size of an appointment representation reaches a firsttype of threshold, the application transitions to state 515 to displayadditional information for the event, then returns to the state 510 tocontinue increasing the time scale. For example, as shown in FIG. 1, theapplication might display the location of an appointment within itsrepresentation (although this may sometimes be displayed by default forthe appointment), the attendees to the appointment, any notes regardingthe appointment, indications as to which invitees have accepted,declined, or replied that they are unsure of attendance, or any otherinformation stored about the appointment.

When the size of an appointment representation reaches a second type ofthreshold, the application transitions to state 520 to increase the textsize for an event in the calendar. In some embodiments, the second typeof threshold only exists when the time scale has been decreased from thedefault time scale (i.e., the hours are smaller than at the defaultscale). That is, the application does not transition to the state 520and increase the size of the text beyond a default text size, but mayincrease the size of text that has previously been decreased from thedefault. For example, if the user provided the pull-apart gestural inputafter the fourth stage 320 of FIG. 3, then the application wouldincrease the text size of some of the appointment representations.

When, instead of receiving the first type of gestural input, theapplication instead receives a second type of gestural input (e.g., thepinch multi-touch gesture shown in FIG. 3), the application transitionsto the state 525 to decrease the size of the time units of the calendarlayout. That is, the application decreases the portion of the calendarlayout that each hour (or half hour, or other time unit) occupies as thegestural input is received, as shown in FIG. 3. As this input continues,the application remains in the state 525 until either a threshold ispassed (causing a transition to state 530 or 535) or the gestural inputceases (causing a transition back to state 505).

As shown, when the size of an appointment representation decreases pasta threshold of the first type, the application transitions to state 530and removes information from the appointment representation, thenreturns to state 525 to continue decreasing the time scale. For example,as shown in FIG. 4, the application might remove the location from thedisplayed appointment representation. Similarly, if the user were toprovide a pinch gesture after the last stage 130 of FIG. 1, then after athreshold was passed the application would remove the attendees from theappointment representation 165. In addition, as shown in FIG. 3, theapplication will remove the text altogether from appointmentrepresentations once those representations become smaller than a certainthreshold.

When the size of an appointment representation in the calendar layoutdecreases past a second type of threshold, the application transitionsto state 535 to decrease the text size for an event in the calendar. Asmentioned above, in some embodiments this second type of threshold onlyexists when the displayed time scale is below the default time scale(i.e., the hours are smaller than at the default time scale). That is,the application only modifies the text size as the appointmentrepresentations are below the default size for their time length, asshown in FIG. 3.

In some embodiments, the application may also transition directly fromthe state 510 to the state 525 (or vice versa) if the user fluidlytransfers from the first type of gestural input to the second type ofgestural input (or vice versa). However, this can also be viewed as aninstantaneous or near-instantaneous transition through the state 505 aswell.

When the application receives a third type of input, which may or maynot be gestural input in different embodiments, the applicationtransitions to the state 540 to return the size of the time units in thecalendar to the default time scale, then returns to the state 505. Insome embodiments, as shown in FIGS. 1 and 4, this input is a double-tapinput. The application, at state 540, may also return all font sizes anddisplayed event information text to the default as well.

II. Handling Time Zones for Appointments

Some embodiments of the invention allow users to specify a time zone foran appointment. When users specify this time zone information for anappointment, the calendar application of some embodiments incorporatesthis information into the representation of the appointment in thecalendar layout. When creating an event, the user may specify a timezone for the event (e.g., the time zone in which the event will takeplace), as well as a start time, end time, etc. in that time zone. Thecalendar application, in some embodiments, displays representations ofthe user's appointments according to the time zone in which the mobiledevice running the application is located. As a result, in some casesthe calendar application displays the calendar in a first time zone,while displaying a representation for an appointment for which a secondtime zone is specified. In such cases, some embodiments display therepresentation at its corresponding time in the first time zone, butindicate within the representation the second time zone and thespecified time in that second time zone for the appointment.

FIG. 6 illustrates a user modifying the time zone for a new event oversix stages 605-630. The first stage 605 illustrates the calendar layoutGUI 100, described in Section I. The user selects the new event creationitem 138 during the first stage 605, in order to create a new event.

The second stage 610 illustrates a new appointment creation GUI 600. Insome embodiments, when the calendar application receives input to createa new appointment, the application displays the appointment creation GUI600. Through this GUI, the user can define various parameters for a newappointment (i.e., appointment characteristics). The user can enter atitle (name) for the event, a location of the event, set start and endtimes, set various parameters such as recurrence, travel time, alerts,etc., and enter invitees for the event. The second stage 610 illustratesthe new appointment creation GUI 600 after the user has entered a title(“Lunch w/John”) and location (“Café Local) for the new appointment. Insome embodiments, selecting the recurrence (“Repeats”) or inviteesoptions cause the application to display additional dialogs throughwhich the user can select a recurrence option or enter invitees. Inaddition, the application provides mechanisms for the user to easilyselect start and end times. As shown, the user selects the start timerow 635 in this stage in order to edit the start time.

The third stage 615 illustrates the resultant start time entry dialog640 that results from the selection of the start time row 635. As shown,the start time entry dialog 640 allows the user, through gestural touchinput (swiping up and down) to modify the day, hour, and minute, as wellas select either morning or afternoon. In addition, upon selection ofthe start time row 635, the application displays a time zone selectionrow 645.

While shown in the GUI 600 as accessible via the start time row 635(i.e., as part of the start time entry dialog), in other embodiments,the time zone selection row 645 is provided as part of the standard newappointment creation GUI (e.g., below the end time row). This time zoneselection row 645, in some embodiments, initially displays a defaulttime zone for a new event. In some embodiments, the default time zone isthe time zone in which the mobile device on which the calendarapplication operates is located. Thus, in this example, the mobiledevice is located in the pacific time zone, and thus the times are givenin Pacific Daylight Time (PDT) and the selected locality is a defaultfor the time zone (“Cupertino”). Some embodiments use the city or otherlocality in which the mobile device is located rather than a defaultlocality for the time zone. In addition, in some embodiments, thedefault time zone is a user-specified setting for the mobile devicerather than the time zone in which the mobile device is located. In thethird stage 615, the user selects the time zone selection row 645.

As a result of this selection, the fourth stage 620 illustrates a timezone selection GUI 650. The time zone selection GUI 650 includes areturn to appointment item 655 (which allows the user to return to thenew appointment creation GUI 600 without modifying the time zone, a textfield 660, a touchscreen keyboard 665, and a list of selectable localityoptions 670. As the user uses the touchscreen keyboard 665 to enter textinto the text field 660, the list of selectable options 670 displays themost likely localities based on the entered text. The most likelylocalities may be determined based on match or near-match (taking intoaccount likely typographical errors) with the text, popularity amongusers of the application generally, past history of the user, andproximity to the current location of the mobile device.

In this case, the user has entered the text “new y” by stage 620,prompting the application to display “New York, U.S.A.” as an option inthe list of selectable options 670. The fifth stage 625 illustrates thatthe user selects the “New York” option at this juncture. As a result,the sixth stage 630 illustrates that the application returns to the newappointment creation GUI 600. The time zone selection row 645 nowindicates that the selected locality for time zone purposes is New York,and the start and end times are now given in Eastern Daylight Time (EDT)rather than PDT. As in this example, some embodiments automaticallyadjust the start and end times for the appointment based on the timezone adjustment. Accordingly, 2 PM PDT became 5 PM EDT, with a similarchange for the end time. On the other hand, some embodiments do notadjust the times, leaving such adjustments up to the user.

FIGS. 7 and 8 illustrate the calendar layout GUI 100 of some embodimentsin two different circumstances for the same calendar. Specifically, FIG.7 illustrates the calendar layout GUI 100 when the mobile device islocated in the Pacific time zone, while FIG. 8 illustrates the calendarlayout GUI 100 for the same schedule when the mobile device is locatedin the Eastern time zone. In this case, after changing the time zone forthe new appointment (“Lunch w/ John”) in FIG. 6, the user modified thetime for that appointment to be May 8, 12 PM EDT. In addition, the userhas scheduled a separate meeting for 1 PM PDT on the same day.

In FIG. 7, the calendar layout 145 includes two appointmentrepresentations 705 and 710. The first appointment representation 705 isfor the appointment “Lunch w/ John”, created for the Eastern time zoneas described above. The second appointment representation 710 is for ameeting (“Meeting 1”), set for 1 PM in the Pacific time zone. The firstappointment representation 705 is displayed in the user's schedule at 9AM, the time in PDT that corresponds to the 12 PM EDT specified time forthis appointment. In addition, the first appointment representation 705includes text indicating the meeting name and location, as well as thespecified time and time zone for the appointment (“12 pm EDT”). On theother hand, the second appointment representation 710 includes text onlyindicating the meeting name and location, but does not include anindication of the specified time zone (because the calendar layoutdisplays the schedule in the time zone specified for the appointment).Furthermore, as shown, some embodiments display the two appointmentrepresentations differently (e.g., different colors, different shades,different patterns, etc.). In addition, other embodiments might indicatethat an appointment is set for a different time zone in other manners.

In FIG. 8, the calendar layout 145 also includes two appointmentrepresentations 805 and 810. Again, the first appointment representation705 is for the appointment “Lunch w/ John” in the Eastern time zone,while the second appointment representation 710 is for the appointment(“Meeting 1”) in the Pacific time zone. Because the user device islocated in the Eastern time zone in this example, the applicationdisplays the first appointment representation 705 in the schedule at 12PM and the second appointment in the schedule at 4 PM, which correspondsto its specified time at 1 PM PDT. Whereas in FIG. 7 the firstappointment representation 705 included extra text indicating that theappointment was specified for Eastern time, in this case the firstappointment representation 805 includes no such text. Instead, thesecond appointment representation 810 includes similar text indicatingthat its appointment was scheduled for 1 PM Pacific time. In addition,the appearance used for the appointment representation 705 is now usedfor the second appointment representation 810, while the defaultappearance used for representation 710 is now used for representation805.

In some embodiments, if the user's schedule for May 8 includedadditional appointments for the Eastern time zone, then the calendarlayout in FIG. 8 would include additional appointment representationshaving the same appearance as that of the representation 805 (therepresentation for appointments in the current time zone). On the otherhand, if the schedule included another Pacific time zone appointment,some embodiments would display the representation for this appointmentusing the same appearance as that of the representation 810. If theschedule included another appointment in a third time zone (e.g.,Central Daylight Time), then some embodiments of the application wouldalso display this third representation using the same appearance as thatof the representation 810 (in addition to indicating the specified timein CDT). On the other hand, other embodiments use a different appearancefor each different time zone, and would thus use a third appearance fora representation of an appointment for which CDT was the specified timezone.

FIG. 9 conceptually illustrates a process 900 of some embodiments fordisplaying appointment representations in a calendar layout.Specifically, the process relates to the display of appointmentrepresentations for appointments with time zones specified, as shown inFIGS. 7 and 8. In some embodiments, the process 900 is performed by acalendar application operating on a mobile device. One of ordinary skillin the art will recognize that the process 900 is part of a largerprocess for displaying a calendar layout in some embodiments, which mayalso include processes relating to the state diagram 500, describedabove, as well as other aspects of the display.

As shown, the process 900 begins by identifying (at 905) events, orappointments, to display in the calendar layout. The calendarapplication of some embodiments accesses a user's schedule or, in somecases, multiple schedules. For example, a user might have multiplecalendars associated with different e-mail addresses, which the calendarapplication aggregates. In different embodiments, the calendarapplication might store the schedule of appointments locally on the userdevice, access the user's schedule in a network storage (e.g., a user'snetwork storage account), or a combination thereof. These appointmentsinclude appointments organized by the user as well as appointmentsorganized by a different individual to which the user is invited and hasaccepted. When identifying appointments to display in the calendarlayout, the application of some embodiments identifies the portion ofthe schedule that will actually be displayed (i.e., the day(s) and hoursto currently display in the calendar application GUI. However, someembodiments perform the process to generate appointment representationsfor other portions of the user's schedule (e.g., upcoming hours or days)that the user may request the application display.

Next, the process 900 selects (at 910) one of the identified events.Some embodiments perform the subsequent looped operations for the user'sappointments in scheduling order, a random or pseudo-random order, etc.In addition, one of ordinary skill in the art will recognize that someembodiments may perform the operations 915-930 for several appointmentsin parallel, rather than generating appointment representations one at atime. For purposes of explanation, however, the process 900 is describedas a linear process.

The process then determines (at 915) whether the time zone specified forthe selected event is the same as the time zone in which the device iscurrently located. In some embodiments, the device on which theapplication operates connects to network stations (e.g., WiFi router,cellular network tower, etc.) which provide time information, includingthe date, time zone, local time, etc. In some embodiments, the calendarapplication automatically displays the schedule in the local time. Thus,even if the default time zone for the device is Pacific time, if theuser In addition, at least some of the appointments include specifiedtime zone information. As shown in FIG. 6, when the user of the calendarapplication creates a new appointment, the user may choose a specifictime zone for the event or use a default time zone, which is stored withthe event in either case. Appointments to which the user is invited byothers will generally have a time zone associated as well.

When the specified time zone for the appointment and the current timezone of the device are the same, the process displays (at 920) arepresentation of the appointment in the calendar layout at thespecified time without additional time zone information. For therepresentation, the process uses an appearance designated forappointments for which the current local time zone is specified. Thatis, the application displays the appointment representation with adefault appearance (e.g., color, shade, border, fill pattern, etc.) usedwhen the specified time zone information for the appointment is the sameas the local time zone. For instance, the appointment representations710 in FIGS. 7 and 805 in FIG. 8 are displayed in this manner. Theprocess 900 then proceeds to 935, described below.

On the other hand, when the specified time zone for the appointment isdifferent than the time zone in which the device is located (andtherefore the time zone for which the schedule is displayed), theprocess 900 identifies (at 925) the appointment time in the current timezone of the device. That is, the application converts the specified timein the first time zone into a second time in the current time zone. Forexample, an event specified for noon in the Eastern time zone will beconverted into 9 AM when the device is operating in Los Angeles, whereasan event specified for noon in the Pacific time zone will be convertedinto 3 PM when the device is operating in New York.

The process then displays (at 930) a representation of the appointmentin the calendar at the identified time in the current time zone (asopposed to the specified time in the specified time zone) along withadditional information about the specified time zone. For therepresentation, the process uses an appearance designated forappointments for which a time zone other than the local time zone isspecified. That is, the application displays the appointmentrepresentation using a different appearance (e.g., color, shade, border,fill pattern, etc.) than that used for appointments for which thecurrent time zone is specified. Some embodiments have one appearanceused for all time zones different from the current time zone, whereasother embodiments use different appearances for appointments withdifferent specified time zones. For instance, the appointmentrepresentations 705 in FIGS. 7 and 810 in FIG. 8 are both displayed witha different appearance than the appointment representations for theevents specified in the local time zone. In some embodiments, as inthese figures, the additional information displayed for non-local eventsis the specified time zone and time in text within the appointmentrepresentation (e.g., the “12 pm EDT” shown in appointmentrepresentation 705. Other embodiments may include additional ordifferent indicators, such as a selectable graphical indicator that theuser can select in order to cause the application to display additionaltime and time zone information about the appointment.

After displaying the representation for the selected event, the processdetermines (at 935) whether additional events remain to be displayed.When the operations 915-930 have not yet been performed for allappointments in the displayed schedule, the process returns to 910 toselect the next appointment. Otherwise, when all identified appointmentshave been processed, the process ends.

III. Commenting on Invitations

The above sections describe various features of the calendar layout GUIof some embodiments. The following section describes a calendar messageuser interface (inbox) of some embodiments, and its use to accept ordecline appointment invitations, as well as to comment on suchappointment invitations. In some embodiments, when a user of thecalendar application declines an appointment (through an invitationmessage in the same inbox in some embodiments), the applicationautomatically provides the user with the ability to add a comment to acommunication that will be sent to the organizer of the appointment,rather than sending the communication right away. The user can then typein a comment (e.g., through a touchscreen keyboard), and accept ordecline other invitations present in the inbox. The calendar applicationholds off on sending the communications indicating acceptance/decliningof an invitation until the user provides input indicating that she hascompleted actions in the inbox (e.g., by returning to the calendarlayout).

FIG. 10 illustrates, over three stages 1005-1015, a user accessing thecalendar message user interface 1000 of some embodiments, also referredto within this document as an inbox. Specifically, in the first stage1005, the user opens the calendar application, then selects the inboxaccess item in the second stage 1010 in order to view the calendarmessage user interface 1000 in the third stage 1015.

The first stage 1005 illustrates a home screen UI 1025. In this UI 1025,the mobile device presents various selectable user interface items, eachrepresenting a different application. These applications may be providedby the manufacturer of the device (e.g., a standard e-mail application,mapping and navigation application, messaging application, etc.), or bythird party application providers (e.g., service-specific applicationssuch as streaming video, social media, etc. applications). In someembodiments, the calendar application is an application provided by themanufacturer of the device. At the first stage 1005, the user selects aselectable item 1020 representing the calendar application. Thisselectable item includes a small badge 1030 with the number “2”, whichindicates that the user has received two new calendar messages.

As a result, the second stage 1010 illustrates that the device hasopened the calendar application, which displays the calendar layout GUI100. The inbox access item 153 includes the number “2”, so as to alsoindicate that the user has received two new calendar messages. In thesecond stage 1010, the user selects the inbox access item 153.

The third stage illustrates the resulting calendar message userinterface 1000 of some embodiments. The calendar message UI 1000includes a set of tabs, with a new messages tab 1035 and a repliedmessages tab 1040. In addition, the calendar message UI includes anactivities completed item 1045, and a messages display area 1050. Thenew messages tab 1035 and the replied messages tab 1040 enable the userto select which sets of messages are displayed in the messages displayarea 1050. Presently, the new messages tab 1035 is selected, andtherefore new messages are displayed in the messages display area 1050.Selection of the activities completed item 1045 causes the applicationto (i) perform any actions specified by the user through the messagesdisplay area (e.g., accept or decline invitations, send comments, etc.)and (ii) return to the calendar layout GUI 100.

The messages display area 1050 displays information about communicationsthat the calendar application has received regarding appointments. Thesemessages may be replies to appointment invitations that the user of thecalendar application has previously sent out, or appointment invitationssent to the user of the calendar application by others to invite thatuser to an appointment. In some embodiments, when the new messages tab1035 is selected, the messages display area displays new communicationsthat the user has not yet interacted with. For instance, for appointmentinvitations received from others, the user can respond by accepting theappointment, declining the appointment, or indicating that she is unsureas to availability (responding with “maybe”) for the appointment. Thefirst message item 1055 shown in the messages display area 1050 is anexample of such an invitation. The invitation displays the meeting name,the organizer of the meeting who sent the invitation, and the time ofthe meeting. Some embodiments may include other information about themeeting, such as any notes or attachments specified by the organizer ofthe meeting. The invitation also displays three selectable options(accept, maybe, and decline). In some embodiments, once the user selectsone of the options and the application sends a communication to theorganizer regarding the user's response, the message will then beavailable via the replied messages tab 1040.

The new messages inbox also displays communications received frominvitees in response to appointment invitations sent to the invitees bythe user of the calendar application. These may replies indicatingacceptance, decline, or a “maybe” response to an invitation, as well ascomments regarding the appointment. When multiple invitees havecommented on and/or declined the appointment, some embodiments aggregatethese communications into a single entry in the user interface. Forinstance, the second message item 1060 shown in the messages displayarea 1050 is an example of a set of such aggregated communicationsreceived in response to an appointment invitation sent by the user ofthe calendar application. Specifically, the user of the applicationorganized the appointment “Meeting 2” and sent the appointment out toseveral invitees. The message item 1060 indicates that two of theseinvitees have declined the invitation. In some embodiments, onlyresponses declining an appointment or commenting on an appointment aredisplayed in the new messages inbox. In this example, two invitees havedeclined, one of whom also commented. In some embodiments, when thecomment does not fit on one line, the application truncates the comment.

In some embodiments, the user can select one of these message items toview further detailed information about the appointment, includinginformation indicating (i) whether invitees have responded, (ii) whatthe invitees' responses indicated, and (iii) whether the invitees hadcomments about the appointment. In addition, some embodiments provide aseparate selectable item for each of the message item (the “ViewComments” item within the message item 1060)) to access a page with moredetailed information about the invitees of the appointment. This page,in some embodiments, also provides indication as to which invitees haveresponded, as well as indicators (e.g., graphical indicators) aboutwhether responding invitees indicated they will attend. In addition, thepage provides the full text of any comments the invitees may have hadregarding the appointment. Rather than combining the first type ofcommunications (e.g., the invitation 1055) and the second type ofcommunication (the comment and/or declining of an appointment 1060),some embodiments provide a third tab for messages relating toappointments organized by the user of the calendar application.

As indicated, when a user of the calendar application of someembodiments declines an appointment through the invitation message item,the application automatically provides the user with the ability to adda comment to a communication that will be sent to the organizer of theappointment, rather than sending the communication right away. The usercan then type in a comment (e.g., through a touchscreen keyboard), andaccept or decline other invitations present in the inbox. The calendarapplication holds off on sending the communications indicatingacceptance/declining of an invitation until the user provides inputindicating that she has completed actions in the inbox (e.g., byreturning to the calendar layout).

FIG. 11 illustrates an example of a user declining an appointment andcommenting on the appointment in the calendar message user interface1000 of some embodiments over six stages 1105-1130. Specifically, theuser selects the decline option for an appointment, then selects a textfield automatically displayed for the declined appointment, enters acomment into the text field, and completes user activities within thecalendar messages UI.

As shown, the first stage 1105 illustrates the calendar messages GUI1000, with three message items 1135-1145 displayed, all three of whichare for new invitations for appointments to which the user of thecalendar application is invited. In some embodiments, the first messageitem 1135 is an invitation to a meeting Thursday at noon, the secondmessage item 1140 is an invitation to a conference call at 2 PM onThursday, and the third message item 1145 is an invitation to dinner at6 PM on Thursday. Each of these message items 1135-1145 lists eventdetails (title, organizer, and date/time), and provides the accept,maybe, and decline selectable options. In the first stage, the userselects the decline option for the message item 1135 by tapping thetouchscreen at the location of the “Decline” text.

The second stage 1110 illustrates that the calendar messages GUI 1000registers the selection of the decline option in three ways. First, thecalendar application lightens the display of the meeting name (e.g., byremoving a bold styling applied to the text, by decreasing the fontsize, etc.) and applies a strikethrough to the meeting name. Secondly,the application displays the “Decline” option as selected at the bottomof the message item. Third, the application displays a text field 1150within the message item 1135, with background text “Comment toOrganizer”. The techniques used in this example to indicate that theuser has selected to decline an appointment invitation are only oneexample of such UI features, and different embodiments may use differenttechniques to indicate a user's choice.

In some embodiments, when the user selects either “Accept” or “Maybe”,the selectable option is highlighted in a similar fashion to that shownfor the “Decline” option in stage 1110. However, the calendarapplication neither modifies the meeting title nor displays a text fieldfor the other two options. In other embodiments, though, the calendarapplication automatically displays the text field when the user selectsany of the three response options. As indicated by the background textof the comment field, the user may use the comment field to enter acomment regarding the appointment with the response that will be sent tothe organizer of the appointment (e.g., the comment “Can't Make it.”shown in the message item 1060 of FIG. 10). The second stage 1110illustrates the user selecting the comment field (e.g., with a tap inputon the location of the comment field).

The selection of the comment field causes the application to display atouchscreen keyboard 1155, as shown in the third stage 1115. Thetouchscreen keyboard 1155, in some embodiments, is a GUI constructprovided by the operating system of the touchscreen device to which thevarious applications are allowed access. When the user selects thecomment field, the background text automatically disappears and theapplication displays a text cursor blinking in the comment field. Asshown at this stage, the user has begun typing the comment “I won't make. . . ” into the comment field, using the touchscreen keyboard.

The fourth stage 1120 illustrates that the user has completed the textinput through the touchscreen keyboard, and provides touch input outsideof the comment field 1150 and touchscreen keyboard 1155 in order toindicate completion of the text entry, at least for the time being. As aresult, the fifth stage 1125 illustrates that the application hasremoved the touchscreen keyboard 1155 from the display. The user alsoselects the activities completed item 1045 in order to leave thecalendar messages GUI. As shown, this causes the calendar application toreturn to the calendar layout GUI 100 of some embodiments in the sixthstage 1130.

The inbox access item 153 in the calendar layout GUI 100 now indicatesthat the user only has two new messages in the inbox rather than three.In some embodiments, when the user selects the activities completed item1045, as shown in the fifth stage 1125, the calendar application sendsout messages based on the response selections entered by the user. Thus,when the user selects the decline option in the second stage 1110, theapplication does not yet send out any communications to the organizer.Even after the user completes entering a comment into the text field andselects elsewhere in the GUI in the fourth stage 1120, the applicationdoes not send either the decline response or the comment to theorganizer of the appointment. This allows the user to respond tomultiple appointments within the calendar messages inbox, edit comments,etc., before any responses are sent out to the organizers of therespective appointments.

FIG. 12 illustrates a user declining multiple appointments in thecalendar messages GUI 1000 over five stages 1205-1225. Specifically, theuser declines multiple events, completes calendar activities in themessages GUI, then returns to the calendar messages GUI with thecompleted activities reflected in the replied messages inbox rather thanthe new messages inbox.

The first stage 1205 illustrates the calendar messages GUI 1000 in thesame state as the fifth stage of FIG. 11. That is, the user has declineda first appointment through the decline option in the selectable messageitem 1135, and has entered a comment into the text field 1150. At thisstage, the user selects the decline option for the second message item1140, in order to decline the conference call appointment. As a result,the application provides a second text field 1230 in the second stage1210, to allow the user to enter a comment regarding the conference callappointment. However, rather than entering a comment, the user selectsthe activities completed item 1045.

The third stage 1215 illustrates the calendar layout GUI 1000. Thecalendar application at this point will have sent communications to theorganizers of the two declined appointments, indicating that the userhas declined these appointments (along with a comment to the organizerof the lunch meeting). As a result of the user declining twoappointments, the inbox access item 153 indicates that only one newmessage remains. The user selects this item in the third stage 1215 inorder to return to the calendar messages GUI 1000.

As such, the fourth stage 1220 illustrates the calendar messages GUI1000, with the new messages tab again selected. However, because thecalendar application has replied to the message items 1135 and 1140,only the message item 1145 remains in the new messages inbox. At thefourth stage 1220, the user selects the replied messages tab. The fifthstage 1225 therefore illustrates the replied messages in the messagedisplay area 1050 of the calendar messages GUI 1000. The message items1135 and 1140, for the appointments that the user declined in theprevious stages, are now displayed in the replied messages inbox.

FIG. 13 illustrates the same flow over five stages 1305-1325 as theprevious figure, except that the user accepts the conference callinvitation rather than declining it. Specifically, in the first stage1305, the user selects the accept option within the message item 1140.Thus, in the second stage 1310, the accept option is highlighted for theconference call message item 1140, and the appointment title has notbeen crossed out. In the fifth stage 1325, the message item for theaccepted appointment also appears with the accept option highlighted.When the user selects the activities completed item 1045 in the secondstage 1310, the calendar application sends a first message to theorganizer of the lunch meeting to decline that appointment and a secondmessage to the organizer of the conference call appointment to acceptthat appointment.

FIG. 14 conceptually illustrates a state diagram 1400 that shows statesand changes between states for the calendar message GUI of someembodiments. Specifically, the state diagram 1400 pertains to thecalendar message GUI when the new messages tab of some embodiments isselected. One of ordinary skill in the art will recognize that thisstate diagram does not cover every possible interaction with thecalendar message GUI, or even the messages display area. For instance,the state diagram does not describe scrolling through the messages whenthe number of message items is too numerous to all fit within thedisplay area at once. Furthermore, the state diagram does not describeinteractions to toggle between the new messages inbox and the repliedmessages inbox, nor does the state diagram describe interactions withmessage items for responses to appointments organized by the user (e.g.,message items such as item 1060 of FIG. 10). For such message items, insome embodiments the user may view appointment details, view an inviteesGUI with comments from the invitees, and acknowledge the message item inorder to cause the application to remove the message item from the newmessages inbox. In each of the states shown in the state diagram 1400,the operations of the calendar application are controlled by one or moreapplication processes that are responsible for handling the userinteraction with the calendar application GUI.

When the calendar messages GUI is open but the user is not interactingwith it, the GUI is in the state 1405, at which the calendar applicationdisplays the new messages display area (the inbox) with all new(unreplied-to) communications. Examples of this state include stage 1015of FIG. 10 or stage 1105 of FIG. 11 (prior to the user selecting thedecline appointment option).

When the application receives the selection of an appointment (shown asan event in the figure), the application transitions to state 1410 todisplay an appointment details GUI. This GUI, described in greaterdetails below by reference to FIG. 23, displays various informationabout an appointment (either an appointment organized by the calendarapplication user or an appointment to which the calendar applicationuser is invited). The appointment details, in some embodiments, indicatethe appointment time, location, and invitee data, as well as otherinformation. In addition, the appointment details GUI of someembodiments includes a return to previous GUI item. Thus, if accessedfrom the calendar messages GUI, the appointment details GUI includes anitem for returning to the calendar messages GUI. Thus, when theapplication receives a selection of this item (or other input forreturning to the calendar messages GUI), the application transitionsback to the state 1405 to again display the calendar messages GUI.

When the application receives a selection for a particular message itemthat the user is unsure of attendance of the appointment (e.g., the“Maybe” option), the application transitions to state 1415 to mark theappointment as a maybe response, then transitions back to the defaultstate 1405. Similarly, when the application receives a selection for aparticular message item that the user accepts the appointment, theapplication transitions to the state 1420 to mark the event as accepted,then transitions back to the default state 1405. In both of theseevents, the application does not actually respond to the selectedappointment invitation by sending any communications to the organizer.The first and second stages 1305 and 1310 of FIG. 13 illustrate anexample of the user accepting an invitation, and the resulting change inthe GUI.

When the application receives a selection for a particular message itemthat the user declines the appointment, the application transitions tothe state 1425 to mark the event as declined. Before transitioning backto the state 1405, the application also transitions to the state 1430 todisplay a comment text field for the appointment. For instance, in FIG.11, when the user selects the decline option in the first stage 1105,the GUI 1000 highlights the decline option, crosses through theappointment title, and displays the comment field 1150 within theselectable message item for the declined appointment in the second stage1110.

So long as at least one appointment with a message item displayed in thecalendar messages GUI has been declined, the user can select the commenttext field for the item (e.g., by tapping the touchscreen at thelocation of the text field). When the application receives such aselection of a text field for comments, the GUI transitions to state1435 and displays a touchscreen keyboard over a portion of the messagesdisplay area. In some embodiments, when the selected comment field islocated at the bottom of the display, the application automaticallyscrolls the message item containing the selected text field up to thetop of the messages display area. With the touchscreen keyboarddisplayed, as the user enters keyboard input, the applicationtransitions to the state 1440 to enter text into the selected textfield. The user may repeatedly enter text, and with each characterentered (or removed) the application transitions to the state 1440 andthen back to the state 1435. When the application receives a selectionoutside of the comment field, the application removes the keyboard fromthe display in order to transition back to the default state 1405 (e.g.,as shown in the fourth and fifth stages 1120 and 1125 of FIG. 11).

Finally, when the application receives input to complete calendarmessaging activities (e.g., selection of the activities completed item1045 or an equivalent input), the calendar application transitions tothe state 1445, at which the application generates and sends responsecommunications for any events from the new messages inbox with responsesmarked by the user. That is, if the user has selected response options(accept/maybe/decline) for any of the appointment invitations in the newmessages inbox, the application sends the response messages for theseappointments to their respective organizers once the user leaves thecalendar messages GUI. In addition, some embodiments allow the user tomodify her responses to appointments through the items in the repliedmessages inbox, and these updated response communications are sent aswell at this time.

The application then transitions to the state 1450 to return to thecalendar layout GUI, in some embodiments. One of ordinary skill in theart will recognize that the application may return to the calendarlayout before actually sending the messages, or perform these actions atthe same time. In addition, though not shown, the application maytransition from state 1450 back to the state 1405 if the user selects aninbox access item or provides equivalent input while the applicationdisplays the calendar layout GUI.

IV. Participant Availability

Whereas the above section primarily described replying to appointmentsorganized by others, the following section relates to features of thecalendar application of some embodiments for organizing appointments.Specifically, the calendar application of some embodiments providesinformation regarding the availability of proposed participants for anew appointment, to aid in scheduling the appointment. In someembodiments, when a user enters a new invitee for an appointment (forwhich the user is the organizer), the application automatically accessesthe invitee's calendar (e.g., by accessing a server) and displays anindicator (e.g., a graphical indicator) that indicates whether or notthe invitee is available at an initially scheduled time for theappointment. When the application cannot access a particular invitee'scalendar (e.g., because the server is inaccessible or the applicationdoes not have the required permissions), then the application displaysan indicator that the invitee's availability is unknown.

Once the user has finished adding invitees for the appointment, theapplication identifies any scheduling conflicts and proposes additionalnew times at which the invitees are available. Some embodiments display(i) the invitees that are not available at the currently scheduled timefor the appointment, (ii) at least one upcoming time at which allinvitees (and the organizer of the meeting), and (iii) upcoming times atwhich various subsets of the invitees are available. The applicationpresents selectable items for each of these upcoming times, enabling theorganizer to select the time as a new time for the appointment, or toview the appointment in her calendar at the upcoming time.

FIGS. 15 and 16 illustrate the creation of an appointment, andspecifically the addition of invitees to an appointment while creatingthe appointment. FIG. 15, over six stages 1505-1530, illustrates thecreation of a new appointment and the addition of a first invitee to theappointment. As shown, the first stage 1505 illustrates the calendarlayout GUI 100, with a user selecting the new appointment creation item138. As a result, the second stage 1510 illustrates the new appointmentcreation GUI 600, described above by reference to FIG. 6. At this stage,the user selects the invitees row 1535.

As illustrated in the third stage 1515, selection of the invitees rowcauses the application to open an invitee addition GUI 1500. The inviteeaddition GUI 1500 provides users with two mechanisms to add invitees tothe new appointment. First, as shown, the GUI displays a text field 1555and touchscreen keyboard 1540. Using the touchscreen keyboard 1540, theuser can type identifying information for an invitee (e.g., e-mailaddress, name, etc.) into the text field 1555. In addition, the GUIincludes an add contact selectable item 1545 which, when selected,causes the application to open a list of the contacts stored for theuser (e.g., on the mobile device, in a network storage, etc.), so thatthe user can search through the list of contacts to find an invitee forthe appointment.

The fourth stage 1520 illustrates that the user has typed a “j” usingthe touchscreen keyboard 1540, in order to begin entering contactidentification information. As a result, the application searchesthrough the user's contact information (e.g., the contact list, e-mailaddresses from which communications have been received, etc.). Theapplication displays, in a potential invitee display area 1550, a listof possible matches for the typed text string. In this case, theapplication displays a first selectable item 1555 for John Duo and asecond selectable item 1560 for Jim Su.

In the fifth stage 1525, the user selects the selectable item 1555 toadd John Duo as an invitee to the new appointment. As such, the sixthstage 1530 displays John Duo in the text field 1555. In addition, nextto the invitee name, the application displays a graphical indicator1560. When the calendar application of some embodiments receives aninvitee for an appointment, the application attempts to access theschedule of the invitee (e.g., by accessing a server or networkstorage). If the user of the calendar application has been grantedaccess to the invitee's schedule and that schedule is accessible, thecalendar application identifies whether the invitee is available or busyat the time of the appointment. The check mark graphical indicator 1560indicates that the invitee John Duo is available from 2 PM to 3 PM onTuesday May 6, the currently scheduled time of the appointment.

FIG. 16 illustrates the continued addition of invitees to the newappointment over six stages 1605-1630. The first stage 1605 is the sameas the sixth stage 1530 of FIG. 15, with John Duo added as a firstinvitee to the appointment. In the second stage 1610, the user types a“b”, and the application presents a selectable item 1635 for thepossible invitee Bob Smith, which the user selects in the third stage1615.

The fourth stage 1620 illustrates that the invitee list now includes BobSmith, with a different graphical indicator 1640 next to his name in thetext field 1555. The graphical indicator 1640 is an X, indicating thatthe application was able to access Bob Smith's schedule, and that he isnot available during at least a portion of the scheduled time for thenew appointment (2-3 PM). In addition, at the fourth stage 1620, theuser begins typing a name of a third invitee.

The fifth stage 1625 illustrates that the application presents aselectable item 1645 for the possible invitee Sam Jr., which the userselects. In the final stage 1630, the invitee list in the text field1555 now includes three invitees. For the third invitee, Sam Jr., theapplication displays a third graphical indicator 1650, which indicatesthat the invitee's schedule was inaccessible (e.g., because the user ofthe calendar application does not have permissions to access Sam Jr.'sschedule). Thus, the application of some embodiments displays one ofthree different graphical indicators for each invitee, depending onwhether the invitee is available, busy, or has an inaccessible schedule.

FIG. 17 conceptually illustrates a process 1700 for displaying such agraphical indicator when an invitee is added to an appointment. In someembodiments, the calendar application performs the process 1700 (or asimilar process) each time the user adds an invitee to a newappointment. In addition, in some embodiments, the application mayperform a similar process when generating other displays regarding theappointment at a later time, in case the schedule of one or more of theinvitees has changed.

As shown, the process 1700 begins (at 1705) when the applicationreceives the addition of a new invitee to a proposed appointment. Asdescribed by reference to FIG. 15, in some embodiments the user can adda new invitee by typing the invitee name or e-mail address, or byopening up a contact list and selecting a contact from that list. Insome embodiments, each invitee is actually an e-mail address. That is,while a person may have multiple e-mail addresses (e.g., a work e-mailaddress, a personal e-mail address, etc.), only one of these addressesis selected as an invitee. In some embodiments, an appointment is alwaysassigned a start and end time when initially created, and the organizermay edit the time of the appointment.

The process then attempts (at 1710) to access a calendar of the invitee(i.e., a schedule) through a network connection. The device on which thecalendar application operates connects to at least one network in someembodiments (e.g., a cellular network, broadband network, etc.). Thecalendar application either attempts to connect directly with a deviceassociated with the invitee, or to a server that stores scheduleinformation for the invitee. For example, in a work environment, anExchange® server or similar type of e-mail and calendar server thatstores employee's calendars may be accessible. For personal e-mailaddresses (e.g., mac.com, gmail.com, etc.), some embodiments contact theservers associated with those e-mail domains to access inviteeschedules.

Next, the process 1700 determines (at 1715) whether the invitee'scalendar is accessible. In some cases, the user of the calendarapplication may not have permission to access the schedule of theinvitee. These permissions, in some embodiments, are granted to thee-mail address of the user which is associated with the appointment, orthe device on which the calendar application runs). In other cases, theserver that stores the invitee's schedule may be inaccessible at thetime, or the invitee may not actually use a scheduling functionality.

When the invitee's calendar is not accessible for any reason, theprocess displays (at 1720) an indication that the availability of theinvitee for the scheduled time of the appointment cannot be determined.Some embodiments use a graphical indicator, such as the question markgraphic 1650 shown in the sixth stage 1630 of FIG. 16. Other embodimentsmay use different graphical indicators, or non-graphical indicators.

When the invitee's calendar is accessible, the process determines (at1725) the availability of the invitee at the scheduled appointment time.Some embodiments classify an invitee as unavailable if the invitee has adifferent appointment scheduled for any portion of the duration of thenew appointment. Other embodiments, however, classify an invitee asavailable if the overlap between scheduled appointments in the invitee'scalendar and the new appointment is small (e.g., less than a thresholdduration, or less than a threshold percentage of the duration of the newappointment). In addition, some embodiments use travel time information,or use a mapping application to calculate travel time betweenappointments to determine whether an invitee will be able to attend anappointment.

The process then determines (at 1730) whether or not the invitee isavailable at the time of the appointment. When the invitee is availableat the scheduled time, the application displays (at 1735) an indicationof this availability. Some embodiments use a graphical indicator, suchas the check mark graphic shown in the sixth stage 1530 of FIG. 15. Onthe other hand, when the invitee is not available at the scheduled time,the application displays (at 1740) an indication of this unavailability.Some embodiments use a graphical indicator, such as the X graphic 1640shown in the fourth stage 1620 of FIG. 16. Other embodiments may usedifferent graphical indicators for these two indications, or usenon-graphical indicators. After displaying one of the three indicators,the process 1700 ends.

In addition to displaying indicators regarding availability, thecalendar application of some embodiments attempts to solve schedulingconflicts. Specifically, some embodiments identify and display (i) theinvitees that are not available at the currently scheduled time for theappointment, (ii) at least one upcoming time at which all invitees (andthe organizer of the meeting), and (iii) upcoming times at which varioussubsets of the invitees are available. The application presentsselectable items for each of these upcoming times, enabling theorganizer to select the time as a new time for the appointment, or toview the appointment in her calendar at the upcoming time.

FIGS. 18 and 19 illustrate an invitee scheduling GUI 1800 of someembodiments for displaying scheduling conflicts and alternate times fora new appointment. FIG. 18 illustrates five stages 1805-1825, in whichthe user completes the addition of invitees to an appointment, navigatesthe scheduling GUI 1800, and requests additional times at which allinvitees are available. FIG. 19 illustrates four stages 1905-1920 inwhich the user continues navigating the scheduling GUI 1800 and requestsadditional times at which subsets of the invitees are available.

The first stage 1805 of FIG. 18 illustrates the invitee addition GUI1500 after the user has added four invitees for a new appointment. Ofthese invitees, John Duo is available at the scheduled time, Bob Smithand Jane Lee are unavailable at the scheduled time, and Sam Jr.'sschedule is inaccessible. The new appointment, though not shown at thisstage, has an initial scheduled time of 1 PM to 2 PM on Thursday, May 8,2014. At this stage, the user (the organizer of the appointment) selectsan activities completed item 1830 to indicate that all of the inviteeshave been added for the appointment.

The calendar application, as a result, displays an invitee schedulingGUI 1800 of some embodiments in the second stage 1810. In someembodiments, the GUI 1800 first lists all of the invitees, divided intotwo sections 1835 and 1840 based on whether the invitee has responded toan invitation from the organizer. At this stage, as the calendarapplication has not yet sent an invitation, all four invitees are in theno response category. Next to the invitee names are graphicalindicators, similar to those displayed in the previous invitee additionGUI 1500, to indicate the availability of the invitees based on theirschedules. In some embodiments, when the invitees have responded,similar graphical indicators are used based on their responses (i.e.,check marks for invitees that have accepted the invitation, questionmarks for invitees that have responded with a maybe response, and Xs forinvitees that have declined the invitation. Each of the listed inviteesis a selectable item, which when selected causes the application todisplay contact information for the invitee in some embodiments. Inaddition, below the no response section 1840 of the GUI is a row 1845that enables the user to access the invitee addition GUI 1500 and addmore invitees to the appointment.

The second and third stages 1810 and 1815 illustrate the user scrollingthrough the GUI 1800, and these two stages will be described inconjunction with the fourth stage 1820 to describe the GUI as a whole.In some embodiments, the font used within the GUI is smaller, and moreof the GUI can fit on the display screen at once. Below the listedinvitees is a scheduling conflict section 1850. The scheduling conflictsection 1850 of some embodiments indicates the initial proposedappointment time (i.e., Thursday, May 8, 2014, from 1 PM to 2 PM in thisexample) and the users that cannot attend at that proposed time. Thisprovides a succinct display to the organizer of the appointment as towhich users are unavailable for the appointment at its currentlyscheduled time. Although shown one below the other, and with first namesonly, some embodiments display the full names of the invitees (e.g.,“Bob Smith”), and display the invitees in two columns. One of ordinaryskill will recognize that various different organizations of theinvitees are possible within each section and subsection. Within thescheduling conflict section 1850 is a check mark indicator 1855, used toindicate that this is the currently selected time for the appointment.In some embodiments, this check mark indicator 1855 is displayeddifferently from the graphical indicators that indicate when an inviteeis available for a proposed appointment time. In addition, thescheduling conflict section 1850 includes a selectable item 1860 forviewing the appointment in the organizer's calendar.

The GUI next includes a section 1865 for displaying selectable itemsrepresenting times when all invitees can attend. In some embodiments, asshown, this section 1865 initially displays one selectable item 1870 fora time when all of the invitees can attend. Some embodiments use theearliest time starting from the current time, while other embodimentsuse the earliest time starting from the proposed time of theappointment. Yet other embodiments use the time closest to the proposedtime of the appointment, irrespective of whether this time is before orafter the proposed appointment. In addition, some embodiments onlysearch for times during business hours (e.g., 9-6 Monday-Friday, or adifferent definition of business hours). Other embodiments do notmandate such restrictions, but rely on the invitees (or the organizer)to have marked off their respective calendars for availability onlyduring certain hours. In this example, the application cannot accessSam's calendar. To handle such situations, some embodiments discountinvitees whose calendar is inaccessible, and only search for times atwhich all of the other invitees (and the organizer) can attend.

In this example, the first time at which all invitees can attend thatfalls within the allowed times is Monday, May 11, 2014. The selectableitem 1870 displays the date and time, as well as a check mark indicatingthat all invitees can attend and a selectable item for viewing theappointment in the organizer's calendar. Furthermore, the section 1865includes a show more selectable item 1875, the selection of which causesthe application to display additional proposed times at which allinvitees can attend.

The fourth stage 1820 illustrates the selection of this item 1875,causing the calendar application display additional selectable items1880 and 1885 for times at which all invitees are able to attend. Thoughnot shown in the fifth stage 1825, some embodiments display selectableitems for all of the time slots (of the same length as the initialproposed time) at which all invitees are able to attend for apre-specified period of time (e.g., one week, two weeks, one month,etc.). The user can scroll through these selectable items in the GUI1800, and choose one of the items in order to specify a new time.

As shown in the third and fourth stages 1815 and 1820, below the section1865 is a section 1890 for displaying selectable items representingtimes at which different subsets of the invitees can attend. The GUIsection 1890 will be described in greater detail by reference to FIG.19, the first stage 1905 of which illustrates the GUI 1800 in the samestate as in the fourth stage 1820 of FIG. 18. At this stage 1905, theuser provides a gestural scrolling input to scroll the GUI upwards andview more of the section 1890 for selectable items representing times atwhich different subsets of the invitees can attend, shown in the secondstage 1910.

In some embodiments, as shown, this section 1890 initially displaysthree selectable items 1925-1935 for different times when some of theinvitees can attend the appointment. Other embodiments only display oneselectable item initially, or display a different number (e.g., two,five, etc.) of selectable items for times at which subsets of inviteescan attend.

Different embodiments sort these times differently. Some embodimentsfirst propose appointment times with the fewest number of unavailableinvitees. For appointment times with equal number of unavailableinvitees (for example, all three selectable items 1925-1935 proposetimes with one unavailable invitee), some embodiments order based on thetime (e.g., earliest starting from current time, earliest starting fromthe proposed time, closest to the proposed time, or a differenttime-based ordering). Other embodiments use a form of time-basedordering as an initial criteria, but avoid having the same invitee orcombination of invitees unavailable for more than one of the initialproposed times (unless there are fewer invitees than the number ofproposed times). Still other embodiments use different ordering for theproposed appointment times (e.g., a solely-time based ordering, withoutconcern for the number of available invitees). In some embodiments, theapplication only proposes times at which the organizer (i.e., the userof the calendar application) is available. In addition, some embodimentsonly search for times during business hours (e.g., 9-6 Monday-Friday, ora different definition of business hours). Other embodiments do notmandate such restrictions, but rely on the invitees (or the organizer)to have marked off their respective calendars for availability onlyduring certain hours. As with the proposed times at which all inviteescan attend, some embodiments discount invitees whose calendar isinaccessible, and only search for times at which subsets of the otherinvitees (and the organizer) can attend.

In this example, the first three times displayed are 2 pm-3 pm and 4pm-5 pm on Friday, May 9 (with Bob and Jane unavailable, respectively),and Monday, May 11, at 9 am (with John unavailable). Each of theselectable items 1925-1935 displays the proposed date and time, as wellas the names of each unavailable invitee, along with a graphicalindicator that denotes their unavailability, and a selectable item forviewing the appointment in the organizer's calendar. Furthermore, thesection 1890 includes a show more selectable item 1940, the selection ofwhich causes the application to display additional proposed times atwhich various subsets of invitees can attend.

The second stage 1910 illustrates the selection of this item 1940,causing the calendar application display additional selectable items fortimes at which all invitees are able to attend. The third stage 1915illustrates the display of additional selectable items for proposedtimes at which different subsets of the users can attend. The thirdstage 1915 also illustrates the user scrolling to reveal additionalproposed times, shown in the fourth stage 1920, a continuation of thesection 1890 of the GUI 1800. Some embodiments display selectable itemsfor all of the time slots (of the same length as the initial proposedtime) at which different subsets of invitees are able to attend for apre-specified period of time (e.g., one week, two weeks, one month,etc.). The user can scroll through these selectable items in the GUI1800, and choose one of the items in order to specify a new time.

In this example, the additional selectable items with proposed timesinclude a selectable item 1945 proposing a time from 9 am-10 am on May 8(at which time both John and Jane are unavailable) and a selectable item1950 proposing a time from 10 am-11 am on May 9 (at which time both Boband Jane are unavailable). These times are closer to the initiallyproposed time of 1 pm-2 pm on May 8 than the proposed times at whichonly one invitee is unavailable, but are listed after them because moreof the invitees are not available.

FIG. 20 illustrates the use of a selectable item for viewing a proposedalternate time in the user's calendar over two stages 2005-2010. In thefirst stage 2005, the invitee scheduling GUI 1800 in the same state asat the second stage 1910 of FIG. 19. Specifically, the stage 2005illustrates three selectable items 1925-1935 for three differentproposed alternate times for an appointment with a scheduling conflict.Each particular one of these selectable items 1925-1935 contains aselectable item to view the proposed time for the particular selectableitem in the user's calendar. The first stage 2005 illustrates the userselecting the item 2015 for a proposed time of 4-5 pm on Friday, May 9.

Thus, the second stage 2010 illustrates the calendar layout GUI 100 ofsome embodiments, with the new appointment slotted into the user'scalendar from 4 pm-5 pm. As shown, some embodiments present arepresentation 2025 of the new appointment with a different appearance(e.g., a different color, fill pattern, border, etc.) from the otherappointment representations in the schedule. In this case, the user doesnot have any appointments abutting the proposed time for the newappointment. In some cases, the user might have meetings that either endat the start time of the new appointment or start at the end time of thenew appointment. In such cases, the user is in the best position todetermine whether the appointments have a good chance to run long, andtherefore whether the proposed time is a good time for the newappointment. The calendar layout GUI 100, when accessed from the inviteescheduling GUI 1800, includes a return to previous GUI selectable item2020, which when selected returns to the invitee scheduling GUI 1800.Other embodiments include an activities completed item (e.g., an itemreading “Done”). In addition, some embodiments do not display the entirecalendar layout GUI, but instead only display the calendar layoutdisplay area along with a selectable item for returning to thescheduling GUI 1800.

FIG. 21 illustrates the selection of one of the alternate proposedtimes, and the effect thereof on the invitee scheduling GUI 1800, overthree stages 2105-2115. The first stage 2105 illustrates the inviteescheduling GUI 1800 in the same state as the third stage 1815 of FIG.18, with the scheduling conflict section 1850 and the section 1865 forproposed times at which all invitees can attend. As shown by thegraphical indicator 1855, the originally proposed time of 1 pm-2 pm onMay 8 is the currently selected time for the appointment. At this stage2105, the user provides a tap input on the selectable item 1870 for theproposed appointment time of 5 pm-6 pm on May 11.

The resultant second stage 2110 illustrates that the check markindicator 1855 is now displayed in the recently selected item 1870, toindicate that the currently selected time for the appointment is now 5pm-6 pm on May 11. In addition, the user scrolls the GUI down to reveal,in the third stage 2115, the no response section 1840 after the item1870 was selected. As shown at this third stage 2115, the calendarapplication of some embodiments updates the graphical indicators for theinvitees in this section based on the newly selected time. As such, forthe three invitees whose calendar is accessible (John, Bob, and Jane),the application displays a check mark indicator to indicate that theinvitee is available at that time. Because Sam's calendar is notaccessible, the application continues to display the question markindicator for him.

FIG. 22 conceptually illustrates a process 2200 of some embodiments forgenerating and preparing proposed times for display in the schedulingGUI. In some embodiments, the calendar application performs the process2200 upon receiving a list of invitees for a new appointment, during theappointment creation flow. The application performs the process 2200 togenerate the scheduling GUI, although only a portion of the GUI maydisplayed on the display screen at a given time due to spaceconstraints.

As shown, the process 2200 begins by identifying (at 2205) that at leastone invitee is busy during a proposed time for a new appointment. Insome embodiments, if all invitees for a new appointment either do nothave accessible calendars or all have the proposed time for the newappointment open on their calendars, then the application does notperform the process 2200. In such embodiments, the application onlydisplays the list of invitees with check mark and/or question markindicators, and does not display the scheduling conflict section or thelists of proposed alternative appointment times.

However, if the calendar of at least one invitee indicates that theinvitee is unavailable, then the application identifies (at 2210) afirst set of upcoming times during which all invitees and the organizerare available. For example, some embodiments analyze the variousinvitees' calendars to identify all time slots, of the same length asthe initial proposed time, within a particular time period during whichall invitees and the organizer (i.e., the user of the calendarapplication) are available. Some embodiments begin the particular timeperiod from the current time, while other embodiments begin theparticular time period from the initial proposed time for theappointment. Still other embodiments use a time period both before andafter the initial proposed time for the appointment (so long as theproposed alternate times are not prior to the current time). In any ofthese cases, various different embodiments may use different timeperiods (e.g., 1 week, 1 month, two days, etc.). In addition, someembodiments restrict the times for proposed appointments to workinghours (e.g., 9-5, 9-6, 8-6, etc., M-F, depending on the definition ofworking hours). Other embodiments rely on the organizer and invitees tohave marked their calendars with their available times in order toimpose such restrictions.

The process then orders (at 2215) the first set of times based on theirstart time. Some embodiments order the first set of times from earliestto latest, while other embodiments order the first set of times based onproximity to the initial proposed time, whether before or after thisinitial proposed time. For example, if the initial proposed time is 1pm-2 pm on Thursday, then an available 12 pm-1 pm time would come beforea 3 pm-4 pm time, which would come before an available 10 am-11 am time.

Next, the process identifies (at 2220) a subset of the first set oftimes to display. For instance, some embodiments begin by onlydisplaying one time at which all invitees are available. Otherembodiments initially display more such times, and in some cases none ofthe times are displayed initially (if there are a large number ofinvitees such that the other portions of the GUI occupy the entiredisplay initially). Furthermore, after the user has selected the “showmore” GUI item, additional times from the first set of times will bedisplayed.

The process 2200 performs a similar set of operations for times at whichsubsets of the invitees are available. As shown, the process identifies(at 2225) a second set of upcoming times, at which both the organizerand at least one invitee are available. Some embodiments analyze thevarious invitees' calendars to identify all time slots, of the samelength as the initial proposed time, within a particular time periodduring which the organizer (i.e., the user of the calendar application)and at least one invitee are available. Some embodiments begin theparticular time period from the current time, while other embodimentsbegin the particular time period from the initial proposed time for theappointment. Still other embodiments use a time period both before andafter the initial proposed time for the appointment (so long as theproposed alternate times are not prior to the current time). In any ofthese cases, various different embodiments may use different timeperiods (e.g., 1 week, 1 month, two days, etc.). In addition, someembodiments restrict the times for proposed appointments to workinghours (e.g., 9-5, 9-6, 8-6, etc., M-F, depending on the definition ofworking hours). Other embodiments rely on the organizer and invitees tohave marked their calendars with their available times in order toimpose such restrictions.

The process then orders (at 2230) the second set of times using thenumber of unavailable invitees as a first criteria and the start time asthe second criteria. Some embodiments first order the second set oftimes such that the alternate times with only one unavailable inviteeare at the beginning of the order (assuming there is at least one suchtime), then the alternate times with two unavailable invitees, and soon. For proposed times with the same number of unavailable invitees,different embodiments may use the different orderings described abovefor the first set of alternate times (e.g., proximity to initialproposed time, earliest to latest starting at current time, earliest tolatest starting at initial proposed time, etc.). In addition, someembodiments further refine the order so as to avoid repeating the samesets of unavailable invitees. For example, if there are four invitees,some embodiments ensure that the first four proposed alternate timesinclude one time at which each of the invitees is unavailable. Afterthis, some embodiments remove other times at which one invitee isunavailable, while other embodiments use the next set of times for eachunavailable invitee.

Lastly, the process 2200 identifies (at 2235) a subset of the second setof times to display. For instance, some embodiments begin by displayingthree times at which all invitees are available. Other embodimentsinitially display fewer or more times (e.g., depending on the number ofinvitees), and in some cases none of the times are displayed initially(if there are a large number of invitees such that the other portions ofthe GUI occupy the entire display initially). Furthermore, after theuser has selected the “show more” GUI item, additional times from thesecond set of times will be displayed.

The process 2200 then ends. One of ordinary skill in the art willrecognize that this is a conceptual process, and the operations may notnecessarily be performed in the order shown. For instance, the calendarapplication might perform the operations 2225-2235 regarding the secondset of times prior to the operations 2210-2220 regarding the first setof times, or perform the two sets of operations in parallel.

The above figures describe the actions of the calendar application ofsome embodiments for handling invitee availability when creating newappointments. After the appointment details are fully determined by theorganizer, the application of some embodiments generates and sends acommunication to each of the invitees informing of the meeting andenabling the invitees to provide a response to the invitation.

In addition, after the appointment has been created, the calendarapplication of some embodiments provides an easy way for the organizerto e-mail all invitees of the appointment. FIG. 23 illustrates anappointment organizer e-mailing all of the invitees over four stages2305-2320 of the calendar application GUIs.

The first stage 2305 illustrates an appointment details GUI 2300 for anexisting appointment. In some embodiments, the user accesses thisappointment details GUI 2300 by selecting an appointment in the calendarlayout, or in various other manners. The appointment details GUI, insome embodiments, first displays the appointment name and timeinformation. In addition, the appointment details GUI includes aninvitee section 2325. As shown, the invitee section 2325 of someembodiments divides the invitees into those who have accepted theappointment invitation, those who have responded that they are unsure ofattending the appointment, those who have declined, and those who havenot responded to the appointment. In addition, some embodiments displaya comment indicator 2330 to indicate that a user has commented on aninvitation. The appointment details GUI 2300 of some embodiments alsodisplays additional information, such as the pertinent calendar for theappointment, any alerts or travel time information, etc. In the firststage 2305, the user selects the invitee section 2325.

As a result, in the second stage 2310 the calendar application displaysan invitee GUI 2335. The invitee GUI 2335 is similar to the inviteescheduling GUI 1800, without the additional information regardingscheduling conflicts and proposed alternative times. Instead, theinvitee GUI 2335 displays the invitees in two sections, a first groupfor invitees who have responded and a second group for invitees who havenot yet responded. The first group includes three invitees in this case,with graphical indicators to indicate each invitees' response.Furthermore, each invitee that has commented on the appointment hastheir comment displayed below their name. At the top, the invitee GUIincludes a selectable item 2340, which the user selects in the secondstage 2310.

The selectable item 2340, shown in this example in the shape of anenvelope associated with e-mail, causes the calendar application togenerate an e-mail to send to all invitees. In some embodiments, thecalendar application provides appointment and invitee data to an e-mailapplication operating on the same device, and the e-mail applicationprepares an e-mail for the user to send after entering any desired text.For instance, the user might want to inform the invitees to bringcertain items to the appointment, or that the event will be startingslightly late, etc.

The third and fourth stages 2315 and 2320 illustrates the e-mail GUI2350 that results from the user's selection of the item 2340. As shown,the e-mail subject (displayed in the subject line and the top of theGUI) is the name of the appointment for which the e-mail was generated.In addition, the to line of the e-mail is populated with the e-mailaddresses of the invitees (showing the invitees' names when theinformation is known), and the cc/bcc/from line populated with theorganizer's name (the user of the calendar application and e-mailapplication). The body of the e-mail includes one or more blank lines insome embodiments (e.g., four blank lines), then includes differentappointment details in different embodiments. Specifically, in thiscase, the e-mail body is populated with the appointment name, date andtime, location, and list of invitees. The user can then type in thedesired message above the appointment details and select the send itemin order to send the e-mail to the invitees. In addition, if theorganizer wishes to omit one or more invitees from the e-mail, she canedit the to field of the e-mail.

V. Intelligent Suggestions for New Appointments

While the above section describes a calendar application feature foridentifying scheduling conflicts and attempting to resolve thoseconflicts once a set of invitees and a time have been determined for anew appointment, the calendar application of some embodimentsautomatically proposes new appointments based on analysis of a user'spast calendar history. Specifically, some embodiments identify patterns(e.g., recurring meetings) in the user's past calendar history, thenpropose appointments that continue such patterns. For example, if theuser has had an appointment with the same name at the same time on thesame day of the week for the past several weeks, then the applicationproposes an appointment with that name at the same time on the nextoccurrence of the particular day of the week. If the recurring time isoccupied by a different appointment, then the application of someembodiments identifies a nearby time (e.g., just before or just after)and proposes the new appointment at the nearby time. If additionaldetails (e.g., the location, invitee list, etc.) are the same or similarthroughout the recurrences, the application uses these additionaldetails for the proposed appointment. Similarly, the application mightidentify appointments held every other week, every day, on the same dayof the month for several months, etc. The application might identifyother patterns, such as the same set of invitees at numerousappointments (with numerous different times and appointment names), andpropose a new appointment for the set of invitees at the next availabletime.

In addition, some embodiments allow the user to enter a text stringdescribing an aspect of the appointment, and identify proposedappointments based on searching through the calendar history for matcheson the text string. The text string might match the name of anappointment, a day on which the appointment was held, the name of aninvitee or set of invitees for the appointment, etc. Once the userselects a proposed appointment in either case, the application adds thisappointment to the calendar of the user, and the user can edit thedetails (e.g., change the time, invitees, location, etc.) before sendinginvitations to the appointment to the finalized list of invitees.

The following section initially describes some embodiments thatautomatically generate proposed appointments upon the selection of a newappointment creation option, by reference to FIGS. 24-28. Followingthis, the section next describes embodiments that generate proposedappointments upon receiving text input describing a desired newappointment, by reference to FIGS. 29-33.

FIG. 24 illustrates a monthly view GUI 2400 of a user's schedule whichwill be used as a reference for the subsequent FIGS. 25-27.Specifically, the monthly view GUI 2400 includes a top bar 2405 thatincludes several tabs 2410 for different calendar views, a search bar, acalendar toggle item, and a new event creation item 2415. The tabs 2410allow the user to switch between different views of the user's schedule,including the monthly view shown in this figure and the daily view shownin FIGS. 25-27, as well as a weekly view and a yearly view.

The new appointment creation item 2415, in some embodiments, causes thecalendar application to display a dialog for creating a new appointmentin the user's calendar. In some embodiments, the new appointmentcreation dialog provides a text field into which the user can enter aname of a new appointment. Upon receiving an additional input (e.g.,pressing the “Enter” key or an equivalent input to indicate completionof the appointment description), the application creates a newappointment in the next available time slot (e.g., the next half hourtime slot, next hour-long time slot, next hour-long time slot beginningon the hour, etc.). The user can also enter additional details into thetext field (e.g., text clearly indicative of a time and/or date), andthe calendar application will account for this information when creatingthe new appointment (e.g., if the text input includes “7 PM Friday” thenthe new appointment will be created at 7 pm on Friday rather than in thenext available time slot). In some embodiments, in addition to this textfield, the application generates proposed appointments based on analysisof the user's calendar history, as described by reference to thesubsequent figures.

Below the top bar 2405 is the user's monthly calendar 2420. As shown,the user of the calendar application displayed in FIG. 24 has a varietyof meetings in the past several weeks, including “Meeting 3” held bothof the previous two Thursdays (the current date, May 15, is selected inthe monthly schedule 2420). In addition, various phone calls and otherappointments are scheduled.

FIG. 25 illustrates the generation of new appointment options in a dailyview GUI 2500 of some embodiments. Specifically, FIG. 25 illustrates twostages 2505-2510 of the GUI 2500. The first stage 2505 illustrates thedaily view GUI 2500 of some embodiments. The calendar layout GUI 2500 isthe GUI for a calendar application that operates on a laptop or desktopcomputer, in some embodiments, although the GUI 2500 may also bedisplayed by a calendar application operating on a mobile device (e.g.,a tablet computer, a smart phone, etc.).

The GUI 2500 includes the top bar 2405 that includes several tabs 2410for different calendar views (with the daily tab now selected), thesearch bar, the calendar toggle item, and the new event creation item2415. The GUI 2500 also includes a miniaturized month view 2525, anupcoming appointments view 2530, and a schedule view 2535. Theminiaturized month view 2525 shows the current day in the calendar andcan be used to select a day for the other two calendar views 2530 and2535. The upcoming appointments view 2530 displays upcoming appointmentsfor the user's schedule, starting with the day selected in theminiaturized month view 2525. The schedule view 2535 displays the user'sschedule for the day selected in the miniaturized month view. In someembodiments, the schedule view 2535 shows the current time (andautomatically begins at the current time), and is scrollable. Theschedule view 2535 displays appointment representations for thescheduled appointments in the user's calendar. In the first stage 2505of FIG. 25, the user selects the new event creation item 2415 (e.g.,with a mouse click, a tap on a touchpad or touchscreen, or otherselection mechanism).

The second stage 2505 illustrates the result of the selection of the newevent creation item 2415. The calendar application automaticallydisplays a fillable text field 2540 with background example text. Theuser may enter text input into this text field 2540 to name a newappointment. Upon receiving an additional input (e.g., pressing the“Enter” key or an equivalent input to indicate completion of theappointment description), the application creates a new appointment inthe next available time slot (e.g., the next half hour time slot, nexthour-long time slot, next hour-long time slot beginning on the hour,etc.). The user can also enter additional details into the text field(e.g., text clearly indicative of a time and/or date), and the calendarapplication will account for this information when creating the newappointment (e.g., if the text input includes “7 PM Friday” then the newappointment will be created at 7 pm on Friday rather than in the nextavailable time slot).

In addition, below the fillable text field 2540, the applicationproposes one or more new appointments based on the past appointments inthe user's calendar history. In some embodiments, the calendarapplication identifies patterns in the user's past calendar history,then proposes appointments that continue such patterns. For example, ifthe user has an appointment with the same name at the same time on thesame day of the week for several weeks, then the application may proposean appointment with that name at the next occurrence of the particularday of the week. Similarly, the application might identify appointmentsheld every other week, every day, every other day, on the same day ofthe month for several months, etc. If additional details (e.g., thelocation, invitee list, etc.) are the same or similar throughout therecurring appointments, the application uses these additional details inthe proposed appointment.

Some embodiments also identify other recurring characteristics ofappointments and propose new appointments with the recurringcharacteristics. For example, some embodiments identify common sets ofinvitees to appointments (which may not follow a regular pattern ofnaming or occurrence), and propose appointments at an arbitrary time(e.g., the next available time slot on the user's calendar) with the setof invitees. Once the user selects one of the proposed appointments, theapplication adds this appointment to the calendar of the user, and theuser can edit the details (e.g., change the time or location, add orremove invitees, etc.) of the appointment.

In the example of FIG. 25, the application proposes two appointmentsbased on the analysis of the user's calendar, and displays selectableitems 2545 and 2550 for these. The first selectable item 2545 proposesan appointment titled “Meeting 3” for 1 PM on the current day (aThursday), because the previous two Thursdays (and possibly additionalprior Thursdays) have had a “Meeting 3” at 1 PM. The selectable item2545 also indicates a location “Office”, which could be the location ofthe previous two meetings with this title. Some embodiments provideadditional details within the selectable items, such as the list ofinvitees for the proposed appointment, and/or other details regardingthe appointment. If the previous iterations of “Meeting 3” includedifferent sets of invitees or different locations, some embodimentsgenerate separate selectable items for the different permutations. Otherembodiments use an algorithm that determines, for each characteristic,which values to use. For instance, some such embodiments first identify,among the recurring appointment instance, which value of thecharacteristic appeared most often. If there is a tie for the most oftenoccurrence of the value, then the application uses the value for thecharacteristic from the most recent occurrence of the recurringappointment. For instance, if “Meeting 3” had a first set of threeinvitees in the first week of May and a second set of four invitees inthe second week of May, some embodiments use the second set of fourinvitees for the proposed appointment, while other embodiments proposetwo separate appointments with all of the details the same except forthe set of invitees.

The second selectable item 2550 proposes an appointment titled “WeeklyDiscussion” for 9 AM the next day (Friday). Some embodiments usecontextual clues in the appointment titles, and the user's calendarincludes an appointment on the previous Friday with the same title. Asthis appointment indicates in its title that it is weekly in nature, theapplication proposes the appointment for the same time in the followingweek, at the same location and with the same additional characteristics.

The second example, FIG. 26, illustrates a similar action performed onthe subsequent Thursday, May 22, over two stages 2605-2610. In the firststage 2605, the user again selects the new appointment creation item2415, and the second stage 2610 again illustrates the resulting proposedappointments based on analysis of the user's calendar history. In thiscase, the user has held a “Meeting 3” on Thursday May 15 at 1 PM, butdid not have another “Weekly Discussion” on Friday May 16.

The second stage 2610 illustrates that the application again displaysthe text field 2540, again with two selectable items 2615 and 2620 fortwo proposed appointments. The first selectable item 2615 proposes a newappointment on the current day for “Meeting 3”, similar to that in theprevious figure. However, in this case, the user already has anappointment “Phone Call 2” scheduled from 1 pm-2 pm, the time slotusually used for “Meeting 3”. Thus, the application identifies the nextavailable time slot, 2 pm-3 pm, and proposes the appointment during thattime slot. Some embodiments identify the next available time slot afterthe time slot determined based on recurrence, while other embodimentsalso look for time slots prior to the time slot determined from therecurring appointments. For example, if the user of the calendarapplication also had an appointment from 2 pm-3 pm, some embodimentswould propose an appointment from 12 pm-1 pm with the selectable item2615.

In both of these examples, the application displays two selectable itemsfor two proposed appointments. Some embodiments always display at leasta minimum number of selectable items for proposed appointments (e.g., atleast one, at least two, etc.). Some embodiments also have a maximumnumber of selectable items that may be displayed (e.g., five proposedappointments). When there is a maximum number, some embodiments assignscores to each proposed appointment (e.g., based on the number of pastoccurrences of the appointment, the extent of similarity between theappointment characteristics of the various occurrences, etc.), anddisplay selectable items for the proposed appointments with the highestscores. When determining the order of the selectable items, someembodiments order the proposed appointments based on their start time(earliest to latest), while other embodiments order the proposedappointments from highest score to lowest score.

FIGS. 27A-B illustrate the selection of one of the proposed appointmentoptions and the subsequent creation of a new appointment in the user'scalendar over five stages 2705-2710. The first stage 2705 illustratesthe GUI 2500 in the same state as the second stage 2510 of FIG. 25, withtwo selectable items 2545 and 2550 for two proposed appointmentsgenerated based on the user's calendar history. At this stage, the userselects (by placing a location indicator over the selectable item in theGUI and providing selection input, although other mechanisms forselection are possible) the second selectable item 2550 in order tocreate a new appointment with the characteristics specified by theappointment.

The second stage 2710 illustrates that the new appointment is createdfrom 9 am-10 am on Friday, May 15. When the application creates the newappointment, some embodiments automatically select the calendar dailyview to the day of the newly created appointment. Thus, as shown, theupcoming appointments view 2530 now starts with Friday, May 16, and theschedule view 2535 displays the schedule for May 16, which includes anappointment representation 2730 for the newly created appointment titled“Weekly Discussion”. In addition, the application automatically displaysan appointment details dialog 2735 that displays the characteristics ofthe appointment and allows the user to modify these characteristics. Forthis appointment, the application automatically generated a title, time,location, set of invitees (John Doe, Jim Smith, and Jane Park), andnotes on the appointment (“We'll be discussing ongoing projects”). Inthis case, the automatically generated appointment does not include anyalerts, travel time information, recurrence data, or attachments, thoughthe user is able to add any of this information if desired. The userselects the appointment time information at this stage 2710.

The third stage 2715 illustrates that the application expands theappointment details dialog 2735 to include all of the time-relatedoptions, including start and end time, recurrence options, travel time,etc. The user selects the end time, and the resulting fourth stage 2720displays various end time options 2740, allowing the user to choose alength and corresponding end time for the appointment. The user selectsthe “11:00 AM: 2 hours” option, and the fifth stage 2725 displays theresult of this selection. The appointment is now 2 hours long, with theappointment representation 2730 modified accordingly.

FIG. 28 conceptually illustrates a process 2800 of some embodiments forautomatically generating proposed appointments upon receipt of an inputto create a new appointment. In some embodiments, this process isperformed by a calendar application operating on a desktop or laptopcomputer, a mobile device, etc., when the user selects a “new event” or“new appointment” option.

The process 2800 begins when the application receives (at 2805) arequest to create a new appointment based on a user's current calendar.In some embodiments, the user selects a user interface feature forcreation of a new appointment (e.g., the selectable GUI item 2415 shownas selected in FIGS. 25 and 26. In other embodiments, the user selectsfrom a drop-down menu, or performs other interaction to create a newappointment.

Upon receiving the request, the process analyzes (at 2810) the user'spast calendar history to identify appointment options for upcoming timeslots. In some embodiments, the user of the calendar application mayhave multiple calendars (e.g., a work calendar, personal calendar,etc.). Some embodiments analyze all of the schedules together, whereasother embodiments only analyze a currently selected schedule. In someembodiments, analyzing the past calendar history to identify appointmentoptions entails identifying patterns in the user's past calendarhistory, then identifying appointments that continue such patterns. Forexample, if the user has an appointment with the same name at the sametime on the same day of the week for several weeks, then the applicationmay identify a possible appointment with that name at the nextoccurrence of the particular day of the week. Similarly, the applicationmight identify appointments held every other week, every day, everyother day, on the same day of the month for several months, etc. Ifadditional details (e.g., the location, invitee list, etc.) are the sameor similar throughout the recurring appointments, the application usesthese additional details in the proposed appointment.

Some embodiments also identify other recurring characteristics ofappointments and propose new appointments with the recurringcharacteristics. For example, some embodiments identify common sets ofinvitees to appointments (which may not follow a regular pattern ofnaming or occurrence), and propose appointments at an arbitrary time(e.g., the next available time slot on the user's calendar) with the setof invitees.

If the previous iterations of a recurring appointment include differentsets of invitees or different locations (or variations in othercharacteristics), some embodiments generate separate possibleappointments for the different permutations. Other embodiments use analgorithm that determines, for each characteristic, which values to usefor a single proposed appointment based on a recurring set ofappointment instance. For instance, some such embodiments firstidentify, among the recurring appointment instance, which value of thecharacteristic appeared most often. If there is a tie for the most oftenoccurrence of the value, then the application uses the value for thecharacteristic from the most recent occurrence of the recurringappointment. For instance, if an appointment held at the same time foreach of the past several weeks had a first set of three invitees in oneof the weeks a second set of invitees in a second one of the weeks, someembodiments use the most recent set of invitees for the proposedappointment, while other embodiments propose two separate appointmentswith all of the details the same except for the set of invitees.

In addition to identifying recurring appointments, some embodiments alsoidentify contextual clues in, e.g., the appointment titles. Forinstance, if the previous week or month included an appointment titled“Weekly Discussion” or “Monthly Review”, some embodiments identify thisas a possible desired new appointment for the next week or month. Someembodiments also identify similar contextual clues in the appointmentnotes, or identify possible recurring appointments in other ways.

Some embodiments always identify at least a minimum number of selectableitems for proposed appointments (e.g., at least one, at least two,etc.). Some embodiments also have a maximum number of proposedappointments that will be displayed to the user. When there is a maximumnumber, some embodiments assign scores to each proposed appointment(e.g., based on the number of past occurrences of the appointment, theextent of similarity between the appointment characteristics of thevarious occurrences, etc.), and display proposed appointments with thehighest scores. When determining the order of the proposed appointmentsfor display, some embodiments order the proposed appointments based ontheir start time (earliest to latest), while other embodiments order theproposed appointments from highest score to lowest score.

With the appointment options identified, the process 2800 performs ascheduling check to make sure that the application does not proposeappointments that overlap with existing appointments in the user'scalendar. Thus, the process selects (at 2815) one of the identifiedappointment options. The application may perform the subsequentoperations on each of the proposed appointment options in random order,from earliest to latest, etc. One of ordinary skill in the art will alsorecognize that some embodiments may not perform the operations in alinear process, one appointment option at a time. Instead, someembodiments perform these operations in parallel for the variousappointment options.

For the selected appointment option, the process determines (at 2820)whether the user is busy during the time slot assigned to thatappointment option. For instance, if the calendar application identifiesa recurring appointment on Fridays from 1 pm-2 pm, but the user has adifferent appointment scheduled at this time (or at other time slotsthat partially or wholly overlap with the identified time, such as 12:30pm-1:30 pm, or 1:30 pm-2 pm), then the user would be busy during theidentified time slot. Some embodiments examine both the calendar of theuser that is selected and to which the appointment will be assigned ifcreated, as well as any other calendars of the user. Other embodimentsonly examine the currently selected calendar for overlappingappointments.

When the time slot is available, the process 2800 presents (at 2825) theappointment option for the identified time slot. On the other hand, whenthe time slot is not available, the process modifies (at 2830) the timeslot for the selected appointment option to an available time slot. Theprocess then presents (at 2835) the appointment option for the modifiedtime slot. In some embodiments, presenting an appointment optionsentails displaying a selectable item in the GUI of the calendarapplication, which the user can select in order to create a newappointment in her calendar with the identified characteristics. FIGS.25-27 above illustrate examples of such proposed appointment options,though some embodiments provide additional details within the selectableitems, such as the list of invitees for the proposed appointment and/orother details regarding the appointment.

When required to modify a time slot for an appointment due to theexistence of a previously-scheduled appointment overlapping or partiallyoverlapping the time slot identified based on recurrence, someembodiments identify the next available time slot after the time slotdetermined based on recurrence. Other embodiments also look for timeslots prior to the time slot determined from the recurring appointments.

After presenting the option (although one of ordinary skill in the artwill recognize that some embodiments actually present all of the optionsto the user at once as selectable items), the process 2800 determines(at 2840) whether additional appointment options were identified thathave not been checked for scheduling. If additional appointment optionsremain, the process returns to 2815 to select another of the identifiedappointment options. Otherwise, the process 2800 ends.

The above description describes the automatic generation of proposedappointments by the calendar application based solely on analysis of theuser's calendar history. In some embodiments, as the user enters textinto the new appointment creation text field (e.g., the text field 2540of FIG. 25), the application searches the user's past calendar historyfor appointments with characteristics that match the text string (e.g.,searching titles, invitee names or e-mail addresses, locations, etc.).The application then proposes new appointments (similar to the proposedappointments discussed above) based on the identified matching pastappointments. These possible new appointments are proposed on days andtimes based on the days and times of the matching past appointments.

Some embodiments of the calendar application propose appointments basedsolely on the calendar history in the manner described above byreference to FIGS. 25-28, while other embodiments require text input inorder to propose appointments based on matching the text input to pastcalendar appointments. Yet other embodiments initially proposeappointments in the manner described above, but then also search formatching appointments and propose appointments in the mannersubsequently described by reference to FIGS. 30-33 once the user beginsentering text input.

FIG. 29, like FIG. 24, illustrates a monthly view GUI 2900 of a user'sschedule. The monthly view GUI 2900 will be used as a reference for thesubsequent FIGS. 30-32. The display of the monthly view GUI 2900 is thesame as that of the GUI 2400, with a top bar 2905 including several tabs2910, a search bar, a calendar toggle item, and a new appointmentcreation item 2915. The tabs 2910, search bar, and calendar toggle itemoperate in the same manner as described above for FIG. 24.

The new appointment creation item 2915, in some embodiments, causes thecalendar application to display a dialog for creating a new appointmentin the user's calendar. In some embodiments, the new appointmentcreation dialog provides a text field into which the user can enter aname of a new appointment. In some embodiments, as with the newappointment creation item 2415 described above, upon receipt ofadditional input the application creates a new appointment in the nextavailable time slot. The user can also enter additional details into thetext field (e.g., text clearly indicative of a time and/or date), andthe calendar application will account for this information when creatingthe new appointment.

In some embodiments, as the user enters text into the text field, theapplication searches through the user's calendar history for previousappointments that match the input text string, or come close tomatching. For instance, as the user enters the text string, theapplication might identify appointment titles, invitee names, locations,etc. that match the text string. The user might also input textindicative of a day or time (e.g., “Tuesday”), causing the calendarapplication to identify appointments that match the input day/time.Based on the matching previous appointments, the calendar applicationgenerates proposed new appointments to present to the user, similar tothe proposed appointments describe by reference to the above figures.

As in the GUI 2400, the monthly view GUI 2900 includes a monthlycalendar 2920, with the current day (May 28) highlighted. The monthlycalendar 2920 indicates that various appointments (dinners, meetings,etc.) were scheduled over the past month.

FIGS. 30 and 31 illustrate the generation of proposed new appointmentoptions in a daily view GUI 3000 of some embodiments based on user textinput. Specifically, FIG. 30 illustrates four stages 3005-3020 of theGUI 3000, in which the application receives selection of the newappointment creation item 2915 and subsequent text input, and thenprovides proposed new appointment creation items based on the textinput.

The first stage 3005 illustrates the daily view GUI 3000 of someembodiments, which is similar to the daily view GUI 2500 describedabove. The GUI 3000 includes the top bar 2905, miniaturized month view3025, an upcoming appointments view 3030, and a schedule view 3035.These GUI sections operate in similar fashion to those described abovefor the GUI 2500 in FIG. 25. The first stage 3005 illustrates that theuser selects the new appointment creation item 2905.

The second stage 3010 illustrates that the application, as a result ofthe selection of the new appointment creation item 2915, displays afillable text field 3040 with background example text, similar to thefillable text field 2540 described above. The user may enter text inputinto the text field 2540 in order to name a new appointment and/orspecify other details about the new appointment. Unlike the example ofFIG. 25, however, the calendar application does not display additionalproposed appointment items at this time.

Instead, the third stage 3015 illustrates that the user has begunentering text into the fillable text field 3040 (e.g., using a keyboard,a touchscreen keyboard if the application operates on a touchscreendevice, etc.). The user has entered the text “Call”. At this stage, theuser has just entered the text, and the application has not yetgenerated any proposed new appointments to display for the user.

The fourth stage 3020 illustrates the display of several selectableitems 3045-3055 representing proposed new appointments based on the textinput and the user's past calendar history. In some embodiments, theapplication provides such selectable items as soon as the user startstyping (e.g., as soon as the user had typed “C” the application wouldhave been presenting possible new appointments based on the letter “C”)and updates these with each keystroke. In other embodiments, as shownhere, the application waits until the user has completed at least aportion of the input (e.g., until a space is received or the inputpauses for a short amount of time).

In this example, the three selectable items 3045-3055 proposeappointments based on matching the text string “Call” to the appointmenttitle for the user's past appointments. The first selectable item 3045is based on the twice-recurring event “Conference Call”, which occurredon Monday, May 12 and Monday, May 19, at 1 pm, but did not occur onMonday, May 26 (possibly due to Memorial Day). Had a conference callbeen scheduled for Tuesday, May 27 at 1 pm, some embodiments wouldrecognize this as a recurrence of the previous two appointments onaccount of the Monday holiday, rather than proposing a Tuesday call forthe following week. The user also had phone calls scheduled on theprevious Thursday at 11 am and 1 pm, and the application proposes newappointments based on these prior appointments with selectable items3050 and 3055. The time slot from 11 am-12 am is open for the user, andtherefore the selectable item 3050 proposes “Call 1” at the same time asthe call from the previous week. However, the time slot from 1 pm-1:30pm is already occupied on Thursday, May 29, so the selectable item 3055instead proposes “Call 2” from 2 pm-2:30 pm.

While in this example all three of the selectable items 3045-3055 arefor proposed appointments based on matches with previous appointmenttitles, some embodiments match on other appointment characteristics aswell. For example, some embodiments match over the invitee names,location, notes, etc. fields that define an appointment. When a userenters a person's name, that name might turn up matches over both theinvitee field (i.e., appointments to which that person is an invitee) aswell as the title field (e.g., appointments for which the person's nameappears in the title).

Once the application identifies the proposed appointments for which todisplay selectable items in the GUI, different embodiments order theselectable items differently. Some embodiments generate the proposedappointments at their specific times, then display the appointments intime order. Other embodiments score each proposed appointment based on avariety of factors, and order the selectable items based on thesescores. For instance, as in the previous examples, more commonlyoccurring appointments might score higher (e.g., the “Conference Call”proposed appointment appearing before “Call 1” or “Call 2” in FIG. 30.Furthermore, some embodiments score the proposed appointments based onthe strength of the match. Thus, matching multiple words in anappointment title scores higher than matching one word, matchingmultiple fields is more indicative of the user's desire than matching asingle field, etc.

FIG. 31 illustrates a second example of the operation of the newappointment creation item 2915 over four stages 3105-3120 of the GUI3000. The first two stages 3105 and 3110 are the same as the first twostages 3005-3010 of FIG. 30, and then in the third stage 3115 the usertypes “Jim” into the fillable text field 3040. The fourth stage 3120illustrates the selectable items 3125 and 3130 displayed based on thistext input. In this case, the user has had a “Meeting 3” appointment at1 pm the last four Fridays, for which a person named Jim is an invitee.As such, the first selectable item 3125 is for another recurrence ofthis meeting. The second selectable item 3130 is for an appointmenttitled “Discuss Jim”, proposed for 5 pm on the following Tuesday. Theuser's calendar, shown in FIG. 29, includes a past appointment with thistitle on an earlier Tuesday at 5 pm.

In this case, the selectable item for “Meeting 3” is listed as the firstoption because it has occurred on each of the past four Fridays.Although some embodiments prefer a match of the appointment title to amatch of an invitee name, a proposed appointment based on a set ofappointments that have occurred repeatedly each week may score higherthan a proposed appointment based on a single appointment that occurredseveral weeks prior.

FIG. 32 illustrates the selection of one of the proposed appointmentitems and the resulting creation of a new appointment in the user'scalendar over two stages 3205-3210. The first stage 3205 illustrates theGUI 3000 in the same state as at the fourth stage 3120 of FIG. 31. Atthis stage, the user selects the first selectable item 3125 in order tocreate a new appointment with the characteristics specified by theappointment.

The second stage 3110 illustrates that the new appointment is createdfrom 1 pm-1:30 pm on Friday, May 15. When the application creates thenew appointment, some embodiments automatically select the calendardaily view to the day of the newly created appointment, as was shown inFIG. 27 above. The application generates and displays an appointmentrepresentation 3215 for the newly created appointment, and displays anappointment details dialog 3220 that displays the characteristics of theappointment and allows the user to modify these characteristics. Forthis appointment, the application automatically generated a title, time,location, invitee (Jim Smith), and notes (“Review of Week”). Asillustrated here, the calendar generated and displayed the selectableitem for the appointment on account of the invitee name “Jim Smith”matching the text string “Jim” input by the user. Though not shown inthis figure, the user could subsequently modify the characteristics ofthe newly created appointment, as was shown in FIG. 27.

FIG. 33 conceptually illustrates a process 3300 of some embodiments forautomatically generating proposed appointments based on matching textinput to a user's past calendar appointment history. In someembodiments, this process is performed by a calendar applicationoperating on a desktop or laptop computer, a mobile device, etc., whenthe user selects a “new event” or “new appointment” option, thenprovides text input (e.g., by typing in a text string).

The process 3300 begins when the application receives (at 3305) textinput describing a new event or appointment. In some embodiments, theuser types this information into a fillable text field displayed by thecalendar application after the application received a selection of a newappointment creation item, as shown in the first three stages of FIGS.30 and 32. In other embodiments, the user enters text input into adifferent GUI construct, such as a permanent text field that does notrequire additional GUI interaction to access.

Upon receiving the text input, the process analyzes (at 3310) the user'spast calendar history to identify events that match the received textinput. In some embodiments, the user of the calendar application mayhave multiple calendars (e.g., a work calendar, personal calendar,etc.). Some embodiments analyze all of the schedules together, whereasother embodiments only analyze a currently selected schedule. In someembodiments, analyzing the user's past calendar history entailssearching the names, invitee lists, locations, notes, attachment filenames, etc. for text strings that match the input string. Someembodiments also identify near-matches (e.g., based on commontypographical errors, such as matching an input of “Meting” with“Meeting”. When multiple words are input, different embodiments usedifferent interpretations of the text string to identify matches in theappointment history. Some embodiments interpret the input “a b” torequire a match of the single string “a b”, other embodiments require amatch of “a” and a match of “b”, while still other embodiments require amatch of either “a” or “b”. Yet other embodiments allow all of these,but prefer a full string match, then a match of both terms, then a matchof one of the terms.

In analyzing the past calendar history, some embodiments do not analyzethe user's entire previous schedule. Instead, different embodiments onlyanalyze appointments a particular amount of time into the past. Forexample, some embodiments only analyze appointments from the priormonth, prior three months, prior year, etc.

Next, the process 3300 generates (at 3315) a set of new proposedappointments with appointment characteristics based on identifiedmatched appointments, and orders (at 3320) the set of new proposedappointments. Some embodiments have a maximum number of proposedappointments that will be displayed to the user, and thus only generateproposed appointments based on this maximum number of matchedappointments. When there are more matching appointments than thismaximum number, some embodiments assign scores to each matched pastappointment or series of appointments and display proposed appointmentswith the highest scores. Some embodiments score the matches based on acombination of the characteristic matched (e.g., preferring title toother appointment characteristics), the type of match (e.g., entirestring matched, all words matched, only one word matched), the recurringnature of the past appointment (e.g., a recurring appointment thatmatches will score higher), etc.

Once the set of matching appointments from which proposed appointmentswill be generated is identified, the calendar application generates theproposed appointments in a similar manner to that described above forFIG. 28. The calendar application of some embodiments identifies thenext day and time occurrence that matches the day/time of the pastappointment, then proposes an appointment at that identified day andtime with the same characteristics as the matched past appointment(e.g., the same name, set of invitees, location, etc.). When the matchedappointment is a recurring appointment with some of the characteristicsvarying between appointment instances (e.g., different sets of inviteesor different locations), some embodiments use an algorithm to determine,for each characteristic, which values to use for the proposedappointment. For instance, some such embodiments first identify, amongthe recurring appointment instance, which value of the characteristicappeared most often. If there is a tie for the most often occurrence ofthe value, then the application uses the value for the characteristicfrom the most recent occurrence of the recurring appointment.

To order the set of proposed appointments (i.e., those that will bedisplayed to the user), some embodiments start with the earliestproposed time. Other embodiments use the scores calculated to determinewhich appointments to propose, with the highest score displayed first(e.g., at the top of a list of selectable items).

With the appointment options identified, the process 3300 performs ascheduling check to make sure that the application does not proposeappointments that overlap with existing appointments in the user'scalendar. Thus, the process selects (at 3325) one of the identifiedappointment options. The application may perform the subsequentoperations on each of the proposed appointment options in random order,from earliest to latest, based on their respective matching scores, etc.One of ordinary skill in the art will also recognize that someembodiments may not perform the operations in a linear process, oneappointment option at a time. Instead, some embodiments perform theseoperations in parallel for the various appointment options.

For the selected appointment option, the process determines (at 3330)whether the user is busy during the time slot assigned to thatappointment option. For instance, if the calendar application identifiesa matching appointment on previous Fridays from 1 pm-2 pm, but the userhas a different appointment scheduled at this time (or at other timeslots that partially or wholly overlap with the identified time, such as12:30 pm-1:30 pm, or 1:30 pm-2 pm), then the user would be busy duringthe identified time slot. Some embodiments examine both the calendar ofthe user that is selected and to which the appointment will be assignedif created, as well as any other calendars of the user. Otherembodiments only examine the currently selected calendar for overlappingappointments.

When the time slot is available, the process 3300 presents (at 3335) theappointment option for the identified time slot. On the other hand, whenthe time slot is not available, the process modifies (at 3340) the timeslot for the selected appointment option to an available time slot. Theprocess then presents (at 3345) the appointment option for the modifiedtime slot. In some embodiments, presenting an appointment optionsentails displaying a selectable item in the GUI of the calendarapplication, which the user can select in order to create a newappointment in her calendar with the identified characteristics. FIGS.30-32 above illustrate examples of such proposed selectable appointmentoptions, though some embodiments provide additional details within theselectable items, such as the list of invitees for the proposedappointment and/or other details regarding the appointment.

When required to modify a time slot for an appointment due to theexistence of a previously-scheduled appointment overlapping or partiallyoverlapping the time slot identified based on recurrence, someembodiments identify the next available time slot after the time slotdetermined based on recurrence. Other embodiments also look for timeslots prior to the time slot determined from the recurring appointments.

After presenting the option (although one of ordinary skill in the artwill recognize that some embodiments actually present all of the optionsto the user at once as selectable items), the process 3300 determines(at 3350) whether additional appointment options were identified thathave not been checked for scheduling. If additional appointment optionsremain, the process returns to 3325 to select another of the identifiedappointment options. Otherwise, the process 3300 ends.

As mentioned above, the processes 2800 and 3300 are not mutuallyexclusive. In some embodiments, the calendar application initiallyperforms the process 2800 (or a similarly functional process) togenerate proposed appointments upon the user's selection of a newappointment item in the calendar application GUI. If the user enterstext rather than selecting one of the proposed appointments, then theapplication performs the process 3300 (or a similarly functionalprocess) to generate proposed appointments that match the entered text.

VI. Electronic System

Many of the above-described features and applications are implemented assoftware processes that are specified as a set of instructions recordedon a computer readable storage medium (also referred to as computerreadable medium). When these instructions are executed by one or morecomputational or processing unit(s) (e.g., one or more processors, coresof processors, or other processing units), they cause the processingunit(s) to perform the actions indicated in the instructions. Examplesof computer readable media include, but are not limited to, CD-ROMs,flash drives, random access memory (RAM) chips, hard drives, erasableprogrammable read-only memories (EPROMs), electrically erasableprogrammable read-only memories (EEPROMs), etc. The computer readablemedia does not include carrier waves and electronic signals passingwirelessly or over wired connections.

In this specification, the term “software” is meant to include firmwareresiding in read-only memory or applications stored in magnetic storagewhich can be read into memory for processing by a processor. Also, insome embodiments, multiple software inventions can be implemented assub-parts of a larger program while remaining distinct softwareinventions. In some embodiments, multiple software inventions can alsobe implemented as separate programs. Finally, any combination ofseparate programs that together implement a software invention describedhere is within the scope of the invention. In some embodiments, thesoftware programs, when installed to operate on one or more electronicsystems, define one or more specific machine implementations thatexecute and perform the operations of the software programs.

A. Mobile Device

The user data sharing of some embodiments occurs on mobile devices, suchas smart phones (e.g., iPhones®) and tablets (e.g., iPads®). FIG. 34 isan example of an architecture 3400 of such a mobile computing device. Asshown, the mobile computing device 3400 includes one or more processingunits 3405, a memory interface 3410 and a peripherals interface 3415.

The peripherals interface 3415 is coupled to various sensors andsubsystems, including a camera subsystem 3420, a wired communicationsubsystem(s) 3423, a wireless communication subsystem(s) 3425, an audiosubsystem 3430, an I/O subsystem 3435, etc. The peripherals interface3415 enables communication between the processing units 3405 and variousperipherals. For example, an orientation sensor 3445 (e.g., a gyroscope)and an acceleration sensor 3450 (e.g., an accelerometer) is coupled tothe peripherals interface 3415 to facilitate orientation andacceleration functions.

The camera subsystem 3420 is coupled to one or more optical sensors 3440(e.g., a charged coupled device (CCD) optical sensor, a complementarymetal-oxide-semiconductor (CMOS) optical sensor, etc.). The camerasubsystem 3420 coupled with the optical sensors 3440 facilitates camerafunctions, such as image and/or video data capturing. The wiredcommunication subsystem 3423 and wireless communication subsystem 3425serve to facilitate communication functions.

In some embodiments, the wireless communication subsystem 3425 includesradio frequency receivers and transmitters, and optical receivers andtransmitters (not shown in FIG. 34). These receivers and transmitters ofsome embodiments are implemented to operate over one or morecommunication networks such as a GSM network, a Wi-Fi network, aBluetooth network, etc. The audio subsystem 3430 is coupled to a speakerto output audio (e.g., to output voice navigation instructions).Additionally, the audio subsystem 3430 is coupled to a microphone tofacilitate voice-enabled functions in some embodiments.

The I/O subsystem 3435 involves the transfer between input/outputperipheral devices, such as a display, a touch screen, etc., and thedata bus of the processing units 3405 through the peripherals interface3415. The I/O subsystem 3435 includes a touch-screen controller 3455 andother input controllers 3460 to facilitate the transfer betweeninput/output peripheral devices and the data bus of the processing units3405. As shown, the touch-screen controller 3455 is coupled to a touchscreen 3465. The touch-screen controller 3455 detects contact andmovement on the touch screen 3465 using any of multiple touchsensitivity technologies. The other input controllers 3460 are coupledto other input/control devices, such as one or more buttons. Someembodiments include a near-touch sensitive screen and a correspondingcontroller that can detect near-touch interactions instead of or inaddition to touch interactions.

The memory interface 3410 is coupled to memory 3470. In someembodiments, the memory 3470 includes volatile memory (e.g., high-speedrandom access memory), non-volatile memory (e.g., flash memory), acombination of volatile and non-volatile memory, and/or any other typeof memory. As illustrated in FIG. 34, the memory 3470 stores anoperating system (OS) 3471. The OS 3471 includes instructions forhandling basic system services and for performing hardware dependenttasks.

The memory 3470 additionally includes calendar application instructions3472 in order for the device 3400 to execute the calendar application ofsome embodiments. The calendar application 3472 may include instructionsto perform some or all of the various features described herein (e.g.,processing touch interactions to resize the time scale of the calendarlayout in the application GUI, handling time zone information forcalendar appointments, processing a user's commenting on appointmentinvitations, scheduling appointments using the calendars of others,proposing appointments based on a user's calendar history, etc.).

The memory 3470 also includes communication instructions 3474 tofacilitate communicating with one or more additional devices (e.g., forpeer-to-peer data sharing, or to connect to a server through theInternet for cloud-based data sharing); graphical user interfaceinstructions 3476 to facilitate graphic user interface processing; imageprocessing instructions 3478 to facilitate image-related processing andfunctions; input processing instructions 3480 to facilitateinput-related (e.g., touch input) processes and functions; audioprocessing instructions 3482 to facilitate audio-related processes andfunctions; and camera instructions 3484 to facilitate camera-relatedprocesses and functions. The instructions described above are merelyexemplary and the memory 3470 includes additional and/or otherinstructions in some embodiments. For instance, the memory for asmartphone may include phone instructions to facilitate phone-relatedprocesses and functions. The above-identified instructions need not beimplemented as separate software programs or modules. Various functionsof the mobile computing device can be implemented in hardware and/or insoftware, including in one or more signal processing and/or applicationspecific integrated circuits.

While the components illustrated in FIG. 34 are shown as separatecomponents, one of ordinary skill in the art will recognize that two ormore components may be integrated into one or more integrated circuits.In addition, two or more components may be coupled together by one ormore communication buses or signal lines. Also, while many of thefunctions have been described as being performed by one component, oneof ordinary skill in the art will realize that the functions describedwith respect to FIG. 34 may be split into two or more integratedcircuits.

B. Computer System

FIG. 35 conceptually illustrates another example of an electronic system3500 with which some embodiments of the invention are implemented. Theelectronic system 3500 may be a computer (e.g., a desktop computer,personal computer, tablet computer, etc.), phone, PDA, or any other sortof electronic or computing device. Such an electronic system includesvarious types of computer readable media and interfaces for variousother types of computer readable media. Electronic system 3500 includesa bus 3505, processing unit(s) 3510, a graphics processing unit (GPU)3515, a system memory 3520, a network 3525, a read-only memory 3530, apermanent storage device 3535, input devices 3540, and output devices3545.

The bus 3505 collectively represents all system, peripheral, and chipsetbuses that communicatively connect the numerous internal devices of theelectronic system 3500. For instance, the bus 3505 communicativelyconnects the processing unit(s) 3510 with the read-only memory 3530, theGPU 3515, the system memory 3520, and the permanent storage device 3535.

From these various memory units, the processing unit(s) 3510 retrievesinstructions to execute and data to process in order to execute theprocesses of the invention. The processing unit(s) may be a singleprocessor or a multi-core processor in different embodiments. Someinstructions are passed to and executed by the GPU 3515. The GPU 3515can offload various computations or complement the image processingprovided by the processing unit(s) 3510. In some embodiments, suchfunctionality can be provided using CoreImage's kernel shading language.

The read-only-memory (ROM) 3530 stores static data and instructions thatare needed by the processing unit(s) 3510 and other modules of theelectronic system. The permanent storage device 3535, on the other hand,is a read-and-write memory device. This device is a non-volatile memoryunit that stores instructions and data even when the electronic system3500 is off. Some embodiments of the invention use a mass-storage device(such as a magnetic or optical disk and its corresponding disk drive,integrated flash memory) as the permanent storage device 3535.

Other embodiments use a removable storage device (such as a floppy disk,flash memory device, etc., and its corresponding drive) as the permanentstorage device. Like the permanent storage device 3535, the systemmemory 3520 is a read-and-write memory device. However, unlike storagedevice 3535, the system memory 3520 is a volatile read-and-write memory,such a random access memory. The system memory 3520 stores some of theinstructions and data that the processor needs at runtime. In someembodiments, the invention's processes are stored in the system memory3520, the permanent storage device 3535, and/or the read-only memory3530. For example, the various memory units include instructions forprocessing multimedia clips in accordance with some embodiments. Fromthese various memory units, the processing unit(s) 3510 retrievesinstructions to execute and data to process in order to execute theprocesses of some embodiments.

The bus 3505 also connects to the input and output devices 3540 and3545. The input devices 3540 enable the user to communicate informationand select commands to the electronic system. The input devices 3540include alphanumeric keyboards and pointing devices (also called “cursorcontrol devices”), cameras (e.g., webcams), microphones or similardevices for receiving voice commands, etc. The output devices 3545display images generated by the electronic system or otherwise outputdata. The output devices 3545 include printers and display devices, suchas cathode ray tubes (CRT) or liquid crystal displays (LCD), as well asspeakers or similar audio output devices. Some embodiments includedevices such as a touchscreen that function as both input and outputdevices.

Finally, as shown in FIG. 35, bus 3505 also couples electronic system3500 to a network 3525 through a network adapter (not shown). In thismanner, the computer can be a part of a network of computers (such as alocal area network (“LAN”), a wide area network (“WAN”), or anIntranet), or a network of networks, such as the Internet. Any or allcomponents of electronic system 3500 may be used in conjunction with theinvention.

Some embodiments include electronic components, such as microprocessors,storage and memory that store computer program instructions in amachine-readable or computer-readable medium (alternatively referred toas computer-readable storage media, machine-readable media, ormachine-readable storage media). Some examples of such computer-readablemedia include RAM, ROM, read-only compact discs (CD-ROM), recordablecompact discs (CD-R), rewritable compact discs (CD-RW), read-onlydigital versatile discs (e.g., DVD-ROM, dual-layer DVD-ROM), a varietyof recordable/rewritable DVDs (e.g., DVD-RAM, DVD-RW, DVD+RW, etc.),flash memory (e.g., SD cards, mini-SD cards, micro-SD cards, etc.),magnetic and/or solid state hard drives, read-only and recordableBlu-Ray® discs, ultra density optical discs, any other optical ormagnetic media, and floppy disks. The computer-readable media may storea computer program that is executable by at least one processing unitand includes sets of instructions for performing various operations.Examples of computer programs or computer code include machine code,such as is produced by a compiler, and files including higher-level codethat are executed by a computer, an electronic component, or amicroprocessor using an interpreter.

While the above discussion primarily refers to microprocessor ormulti-core processors that execute software, some embodiments areperformed by one or more integrated circuits, such as applicationspecific integrated circuits (ASICs) or field programmable gate arrays(FPGAs). In some embodiments, such integrated circuits executeinstructions that are stored on the circuit itself. In addition, someembodiments execute software stored in programmable logic devices(PLDs), ROM, or RAM devices.

As used in this specification and any claims of this application, theterms “computer”, “server”, “processor”, and “memory” all refer toelectronic or other technological devices. These terms exclude people orgroups of people. For the purposes of the specification, the termsdisplay or displaying means displaying on an electronic device. As usedin this specification and any claims of this application, the terms“computer readable medium,” “computer readable media,” and “machinereadable medium” are entirely restricted to tangible, physical objectsthat store information in a form that is readable by a computer. Theseterms exclude any wireless signals, wired download signals, and anyother ephemeral signals.

While the invention has been described with reference to numerousspecific details, one of ordinary skill in the art will recognize thatthe invention can be embodied in other specific forms without departingfrom the spirit of the invention. In addition, a number of the figures(including FIGS. 4 and 5) conceptually illustrate processes. Thespecific operations of these processes may not be performed in the exactorder shown and described. The specific operations may not be performedin one continuous series of operations, and different specificoperations may be performed in different embodiments. Furthermore, theprocess could be implemented using several sub-processes, or as part ofa larger macro process. Thus, one of ordinary skill in the art wouldunderstand that the invention is not to be limited by the foregoingillustrative details, but rather is to be defined by the appendedclaims.

1. (canceled)
 2. An electronic device, comprising: a display; one ormore processors; and memory storing one or more programs configured tobe executed by the one or more processors, the one or more programsincluding instructions for: displaying, via the display, a userinterface comprising notifications of one or more proposed appointmentsfor which a user of a calendar application is a proposed attendee;receiving a set of one or more inputs corresponding to an option todecline one of the one or more proposed appointments; and in response tothe set of one or more inputs and prior to sending a communication to anorganizer of the one of the one or more proposed appointments that isdeclined, providing a text field for receiving a textual commentregarding the one of the one or more proposed appointments that isdeclined.
 3. The electronic device of claim 2, further includinginstructions for: receiving input to complete calendar activities in theuser interface; and sending a communication to the organizer of the oneof the one or more proposed appointments in response to the input tocomplete calendar activities.
 4. The electronic device of claim 2,wherein the one of the one or more proposed appointments that isdeclined is a first proposed appointment, the one or more programsfurther including instructions for: receiving input to accept a secondproposed appointment of the one or more proposed appointments.
 5. Theelectronic device of claim 4, wherein no communication is sent regardingeither the first or second proposed appointments until additional inputis received indicating that user activities are completed for the userinterface.
 6. The electronic device of claim 2, wherein the one of theone or more proposed appointments that is declined is a first proposedappointment, the one or more programs further including instructionsfor: prior to sending the communication, receiving input to respond to asecond proposed appointment of the one or more proposed appointments. 7.The electronic device of claim 6, wherein the one or more programsfurther include instructions for: in response to the input to respond tothe second proposed appointment, providing a second text field forreceiving a textual comment regarding the second proposed appointment.8. The electronic device of claim 7, wherein the one or more programsfurther include instructions for: receiving input to complete calendaractivities in the user interface; and sending (i) a first communicationto an organizer of the first proposed appointment and (ii) a secondcommunication to an organizer of the second proposed appointment.
 9. Theelectronic device of claim 2, wherein the one or more programs furtherinclude instructions for: receiving text input for the text field;receiving input to complete calendar activities in the user interface;and sending a communication to the organizer of the one of the one ormore proposed appointments that is declined, the communicationcomprising the text input as a comment regarding the one of the proposedappointments that is declined.
 10. The electronic device of claim 2,wherein the one or more programs further include instructions for:receiving a set of one or more inputs to respond to a plurality ofdifferent proposed appointments, wherein no communication is sentregarding any of the plurality of different proposed appointments priorto receiving input to complete activities in the user interface.
 11. Theelectronic device of claim 10, wherein the set of one or more inputs torespond to the plurality of different proposed appointments comprises aninput declining a first proposed appointment of the one or more proposedappointments, an input accepting a second proposed appointment of theone or more proposed appointments, and an input responding as undecidedto a third proposed appointment of the one or more proposedappointments.
 12. A computer-readable medium storing one or moreprograms configured to be executed by one or more processors of anelectronic device that is in communication with a display, the one ormore programs including instructions for: displaying, via the display, auser interface comprising notifications of one or more proposedappointments for which a user of a calendar application is a proposedattendee; receiving a set of one or more inputs corresponding to anoption to decline one of the one or more proposed appointments; and inresponse to the set of one or more inputs and prior to sending acommunication to an organizer of the one of the one or more proposedappointments that is declined, providing a text field for receiving atextual comment regarding the one of the one or more proposedappointments that is declined.
 13. A method, comprising: at anelectronic device having a display: displaying, via the display, a userinterface comprising notifications of one or more proposed appointmentsfor which a user of a calendar application is a proposed attendee;receiving a set of one or more inputs corresponding to an option todecline one of the one or more proposed appointments; and in response tothe set of one or more inputs and prior to sending a communication to anorganizer of the one of the one or more proposed appointments that isdeclined, providing a text field for receiving a textual commentregarding the one of the one or more proposed appointments that isdeclined.